Akıllı Sözleşme Nedir?

Ethereum'un iki yaygın hesap türü vardır: Dışarıdan Sahip Olunan Hesaplar (EOA) ve Akıllı Sözleşme Hesapları (SCA).

EOA'lar, genellikle fon saklamak ve uygulamalarla etkileşimde bulunmak için kullandığımız elektronik finansal hesaplara çok benzerdir. Örneğin, kullanıcılar PayPal aracılığıyla fiat para yatırır ve çeşitli web siteleri, mağazalar ve uygulamalarla ödemeler için etkileşime girerler. DeFi madencileri genellikle kripto paralarını EOA'larında saklarlar, DeFi dApp'leri ile etkileşime girerler ve kâr elde etmek için dApp'lere fon yatırırlar. Ancak EOA'ların elektronik finansal hesaplarda bulunmayan bir özelliği vardır: kullanıcıların EOA üzerindeki kontrollerinin özel anahtarların sahipliği ile doğrulanması gerekir - anahtarlarınız sizin değilse, coinleriniz de sizin değildir.

SCA'lar da esasen yürütülebilir bir bayt kodu segmentiyle (akıllı sözleşme olarak da bilinir) ilişkili bir hesap türüdür. Akıllı sözleşme, çeşitli iş mantığını tanımlar ve dApp'ler için arka uç görevi görür. Bununla birlikte, geleneksel Turing-complete geliştirme dillerine kıyasla daha fazla kısıtlamaya sahip olmalarına rağmen, yarı-Turing-complete akıllı sözleşmeler hâlâ çok sayıda saldırıya karşı savunmasız kalmış ve blok zinciri endüstrisine sayısız darbe vurmuştur.

Yaygın Akıllı Sözleşme Saldırıları

1. Yeniden Giriş Saldırısı

En yaygın ve kötü şöhretli saldırı, Ethereum Classic'in oluşmasına yol açan Ethereum çatallanmasından sorumlu olan yeniden giriş saldırısıdır. 2016'da, saldırganlar The DAO sözleşmesine yönelik bir yeniden giriş saldırısı gerçekleştirerek, o zamanki değeri 150 milyon doların üzerinde olan 3.600.000 ETH çaldılar. Ethereum'un erken aşamalarında meydana gelen bu saldırı, ekosistemi tahrip etti ve yatırımcı güvenini sarstı, sonuçta bir çatallanmaya yol açtı.

Özel Mantık

Yeniden giriş saldırısının prensibini daha iyi anlamanız için bir örnek verelim. B Bankası daha önce A Bankası'na biraz para ödünç vermişti. Bir gün, B Bankası A Bankası'na bir transfer başlatır ve tüm paranın B Bankası'na geri aktarılmasını talep eder. Normal süreç şu şekildedir:

Adım 1: B Bankası fon çekme talebinde bulunur

Adım 2: A Bankası fonları B Bankası'na transfer eder

Adım 3: A Bankası, B Bankası'na başarılı transferi onaylar

Adım 4: A Bankası, B Bankası'nın hesap bakiyesini günceller.

Ancak, B Bankası 2. Adımdan sonra bir açık oluşturursa ve 3. Adımda onay almadan A Bankası'ndan tüm parayı talep etmeye devam ederse, A Bankası'nın B Bankası'ndaki hesap bakiyesi değişmeden kalacaktır. Bu özyinelemeli çağrı, A Bankası'nın tüm varlıklarını tüketecektir.

İlgili Akıllı Sözleşmeler

A Bankası'nın sözleşmesi iki işlev içerir:

deposit(): A Bankası'na para yatıran ve kullanıcının bakiyesini güncelleyen bir yatırma işlevi;
withdraw(): Kullanıcıların A Bankası'ndan tüm fonlarını çekmelerine izin veren bir çekme işlevi.

B Bankası'nın saldırı sözleşmesi, temel olarak receive() geri çağırma işlevini tetikleyen bir döngü içerir. Bu işlev, sırasıyla 1 yatırma, 1 çekme ve receive() geri çağırma işlevi çağrılarıyla A Bankası'nın varlıklarını tüketmek için Banka sözleşmesinin withdraw() işlevini çağırır ve sonunda B'nin A'daki bakiyesini günceller. İki işlev içerir:receive(): ETH alındığında tetiklenen ve çekme işlemleri yapmak için Banka sözleşmesinin withdraw() işlevini özyinelemeli olarak çağıran bir geri çağırma işlevi.
attack(): İlk olarak bakiyeyi yenilemek için Banka sözleşmesinin deposit() işlevini çağırır, ardından ilk çekmeyi başlatmak için withdraw() işlevini çağırır ve Banka sözleşmesinin varlıklarını tüketmek için özyinelemeli olarak withdraw() işlevini çağırmak üzere receive() geri çağırma işlevini tetikler.

Çözüm

Yeniden giriş kilidi uygulama

Yeniden giriş kilidi, yeniden girişi önlemek için kullanılan bir değiştiricidir ve bir çağrının yeniden çağrılabilmesi için yürütmesini tamamlaması gerektiğini sağlar. Örneğin, Bank B'nin saldırısı Bank sözleşmesinin withdraw() fonksiyonunu birden çok kez çağırmayı gerektirdiğinden, yeniden giriş kilidi uygulamasıyla başarısız olacaktır.

Nasıl Kullanılır

2. tx.origin'in yanlış kullanımı

Akıllı bir sözleşmede tx.origin'in ana işlevi, işlemi başlatan orijinal hesabı almaktır. Burada, akıllı sözleşmelerdeki iki yaygın değişkeni tartışacağız: msg.sender ve tx.origin . msg.sender akıllı sözleşmeyi doğrudan çağıran hesabı alırken, blok zinciri dünyasında, farklı akıllı sözleşmelerin iç içe geçmiş ve karşılıklı çağrıları nedeniyle (DeFi Lego gibi), işlemi başlatan orijinal hesabı elde etmek için tx.origin gereklidir. dApp geliştiricileri kodda yalnızca tx.origin 'in güvenliğini doğruladığında ve saldırganların tx.origin 'i atlamak ve saldırı başlatmak için ara sözleşmeler dağıtmasının güvenlik doğrulamasını ihmal ettiğinde bir güvenlik açığı ortaya çıkar.

Özel Mantık

İşte sizi yaygın saldırı senaryosuna derinlemesine sokmak için bir örnek. Bill'in, Bill'in bir transferin başlatıcısı olup olmadığını doğrulayan akıllı bir cüzdanı var. Bir keresinde Bill bir kimlik avı web sitesinde bir NFT bastı. Bu, web sitesinin Bill'in kimliğini elde etmesine ve kimliğini kullanarak akıllı cüzdanından bir transfer başlatmasına izin verdi, bu da varlık kayıplarına neden oldu. Normal şartlar altında, kullanıcıların bu tuzağa düşme olasılığı daha düşüktür, ancak bir cüzdan kullanarak dApp'lerle etkileşimde bulunurken genellikle etkileşim istemlerini kontrol etmeyi unuturlar. Örneğin, her ikisi de Mint() işlevini içeriyorsa, dikkatsiz kullanıcılar kolayca bir kimlik avı tuzağına düşebilir. Kimlik avı web sitesinin iş mantığı tuzaklarla doludur, bu nedenle normal etkileşimler sırasında etkileşim istemlerinde hata olup olmadığını kontrol etmek önemlidir.

Akıllı Cüzdan Sözleşmesi

Akıllı cüzdan sözleşmesi bir işlev içerir:

transfer(): Yalnızca cüzdan sahibi tarafından başlatılabilen bir para çekme işlevi, ki bu durumda Bill'dir.

Kimlik Avı Saldırısı Sözleşmesi

Bir kimlik avı saldırısı sözleşmesinde, Mint() kullanıcıları fonları bir hackerin adresine transfer etmeye teşvik eder. Bir işlev içerir:

Mint(): Çağrıldığında, kimlik avı işlevi dahili olarak Wallet sözleşmesinin transfer() fonksiyonunu yürütür. Orijinal başlatıcı kullanıcının (bu örnekte Bill) kendisi olduğundan, verification require(tx.origin == owner, "Not owner"); bir sorun teşkil etmeyecektir. Ancak, transfer için hedef adres zaten hackerin adresine değiştirilmiş olduğundan, fon hırsızlığıyla sonuçlanır.

Çözümler

1. tx.origin yerine msg.sender kullanın

Ne kadar çok sözleşme çağrısı olursa olsun (Sözleşme A → Sözleşme B →…→ hedef sözleşme), yalnızca msg.sender'ı, yani doğrudan çağıranı doğrulayarak, kötü niyetli ara sözleşmelerin neden olduğu saldırılardan kaçının.

2. tx.origin == msg.sender doğrulaması yapın

Bu yöntem kötü niyetli sözleşmeleri uzak tutabilir, ancak geliştiricilerin kendi iş gerçekliklerini göz önünde bulundurmaları gerekir çünkü bu yöntem etkili bir şekilde diğer tüm harici sözleşme çağrılarını izole eder.

3. Rastgele Sayı Üreteci (RNG) Saldırısı

Bu, 2018 ve 2019 civarında kumar veya bahis dApp'larının trendine dayanmaktadır. Tipik olarak, geliştiriciler çekilişler sırasında kazananları seçmek için akıllı sözleşmelerde belirli tohumları kullanarak rastgele sayılar üretirler. Yaygın tohumlar arasında block.number, block.timestamp, blockhash ve keccak256 bulunur. Ancak, madenciler bu tohumları tamamen kontrol edebilir, bu nedenle bazı durumlarda kötü niyetli madenciler fayda sağlamak için değişkenleri manipüle edebilir.

Yaygın Zar Sözleşmeleri

Zar sözleşmesi bir işlev içerir:

Bet(): Kullanıcıların bir bahis numarası girdikleri ve bir ETH ödedikleri bir bahis işlevi. Birden fazla tohumla rastgele bir sayı üretilir ve bahis numarası rastgele sayıyla eşleşirse, kullanıcı tüm ödül havuzunu kazanır.

Madencinin Saldırı Sözleşmesi

Madenciler, kazanan rastgele sayıyı önceden hesaplayıp aynı blokta yürüttükleri sürece kazanabilirler. Bu, bir işlev içerir:

attack(): Madencinin kazanan rastgele sayıyı önceden hesapladığı bir bahis saldırı işlevi. Aynı blokta yürütüldüğü için, blockhash(block.number - 1) ve block.timestamp aynı blokta aynıdır. Ardından madenci, saldırıyı tamamlamak için Zar sözleşmesinin Bet() işlevini çağırır.

Çözüm

Oracle projeleri tarafından sağlanan zincir dışı rastgele sayıları kullanın

Chainlink gibi oracle projelerinin sağladığı hizmetler aracılığıyla, rastgeleliği ve güvenliği sağlamak için zincir üstü rastgele sayılar zincir üstü sözleşmelere enjekte edilir. Ancak, oracle projeleri de merkezileşme riskleri taşımaktadır, bu nedenle daha olgun oracle hizmetlerine ihtiyaç duyulmaktadır.

4. Tekrar Saldırısı

Tekrar saldırısı, fonları çalmak için daha önce kullanılmış bir imzayı kullanarak bir işlemi yeniden başlatmayı içerir. Son yıllardaki en bilinen tekrar saldırılarından biri, Optimism üzerindeki piyasa yapıcı Wintermute'dan 20 milyon $OP token'ının çalınmasıydı ve bu bir zincirler arası tekrar saldırısıydı. Wintermute'un çoklu imza cüzdan hesabı geçici olarak yalnızca Ethereum ana ağında dağıtıldığı için, saldırgan Wintermute'un Ethereum'da çoklu imza adresi dağıtımı için işlem imzasını kullanarak aynı işlemi Optimism zincirinde yeniden yürüttü ve böylece Optimism'deki çoklu imza cüzdan hesabının kontrolünü ele geçirdi. Çoklu imza cüzdan hesabı esasen akıllı bir sözleşme hesabıdır ve bu da SCA ile EOA arasındaki önemli bir farkı gösterir. Bir EOA için, normal bir kullanıcının Ethereum ve EVM uyumlu zincirlerdeki tüm adresleri kontrol etmek için sadece bir özel anahtara ihtiyacı vardır (adres dizeleri tam olarak aynıdır), oysa bir SCA yalnızca dağıtıldıktan sonra bir zincirde etkilidir.

Özel Mantık

Burada, tipik bir tekrar saldırısının (aynı zincir tekrar saldırısı) bir örneğini sunuyoruz. Bill'in her işlem yürütülmeden önce elektronik imzasını girmesini gerektiren akıllı bir cüzdanı var. Şimdi hacker Lucy, Bill'in elektronik imzasını çaldığı için, Bill'in akıllı cüzdanını boşaltmak için sınırsız sayıda işlem başlatabilir.

Örnek

Güvenlik açıkları olan bir sözleşme üç işlevden oluşur:

checkSig(): ECDSA doğrulama işlevi, doğrulama sonucunun orijinal olarak ayarlanmış imzalayan olduğunu garanti eder.
getMsgHash(): Hash oluşturma işlevi, to ve amount'u birleştirerek hash oluşturur.
transfer(): Transfer işlevi, kullanıcıların likidite havuzundan fonları çekmesine izin verir. İmza üzerinde kısıtlamalar olmadığı için, aynı imza yeniden kullanılabilir ve bu da saldırganların sürekli olarak fonları çalmasına olanak tanır.

Çözüm

Tekrar saldırılarını önlemek için imza kombinasyonuna nonce dahil edin. Parametrenin prensibi aşağıdaki gibidir:

nonce: Blok zinciri ağındaki bir EOA'nın işlem sayısının değişkenini tanımlar. Sıralı ve benzersizdir. Her ek işlemle birlikte nonce değeri 1 artar. Blok zinciri ağı, işlemin nonce'unun hesabın mevcut nonce'u ile tutarlı olup olmadığını kontrol edecektir. Bu nedenle, bir hacker kullanılmış bir imzayı kullanmaya çalışırsa başarısız olur çünkü imza kombinasyonundaki nonce değeri EOA'nın mevcut nonce değerinden düşüktür.

5. Hizmet Reddi (DoS) Saldırısı

Hizmet Reddi (DoS) saldırısı, geleneksel Web2 dünyasında yeni bir şey değildir. Bir sunucuya yönelik, büyük miktarda gereksiz veya bozucu bilgi göndererek kullanılabilirliği engelleyen veya tamamen yok eden herhangi bir müdahaleyi ifade eder. Benzer şekilde, akıllı sözleşmeler de bu tür saldırılardan muzdariptir ve temel olarak akıllı sözleşmenin arızalanmasını hedefler.

Özel Mantık

Bir örneğe bakalım. Proje A, protokol tokeni için halka arz düzenliyor; burada tüm kullanıcılar ilk gelen ilk alır esasına göre kota satın almak için likidite havuzuna (Akıllı Sözleşme) fon katkısında bulunabilir ve fazla fonlar katılımcılara iade edilecektir. Hacker Alice, halka arza katılmak için saldırı sözleşmesini kullanır. Likidite havuzu Alice'in saldırı sözleşmesine fon iade etmeye çalıştığında, bir DoS saldırısı tetiklenir ve iade işleminin gerçekleşmesi engellenir. Sonuç olarak, büyük miktarda fon akıllı sözleşmede kilitli kalır.

Halka Arz Sözleşmesi Örneği

Örnek

Halka arz sözleşmesi iki işlev içerir:

deposit(): yatırma işlevi, yatırımcının adresini ve katkıda bulunduğu miktarı kaydeder.
refund(): geri ödeme işlevi, proje ekibinin yatırımcılara fonları iade etmesini sağlar.

DoS Saldırı Sözleşmesi

DoS saldırı sözleşmesi bir işlev içerir:

attack(): Bir saldırı işlevi olmasına rağmen, herhangi bir sorunu yoktur. Asıl sorun, Hacker sözleşmesine yerleştirilmiş receive() ödeme geri çağırma işlevinde yatmaktadır. Bu işlev, istisnaların bir değerlendirmesini içerir. Hacker sözleşmesine fon aktaran herhangi bir dış sözleşme, revert() aracılığıyla bir istisna tetikleyecek ve böylece işlemin tamamlanmasını engelleyecektir.

Çözümler

1. Kritik işlevselliğin dış sözleşmeler çağrıldığında takılmasını önlemek

PublicSale sözleşmesinin yukarıdaki refund() işlevinden require(success, "Refund Fail!"); ifadesini kaldırın. Bu, tek bir adrese geri ödeme başarısız olsa bile geri ödeme işleminin devam edebilmesini sağlar.

2. Ayrıştırma

PublicSale sözleşmesinin yukarıdaki refund() işlevinde, geri ödemeleri dağıtmak yerine kullanıcıların kendi geri ödemelerini talep etmelerine izin verin. Bu, dış sözleşmelerle gereksiz etkileşimleri en aza indirir.

6. permit Saldırısı

Bir izin saldırısında, A Hesabı önceden belirlenmiş bir tarafa imza sağlar ve ardından B Hesabı, imzayı elde ettikten sonra, belirli miktarda token çalmak için yetkili token transferlerini gerçekleştirebilir. Burada, öncelikle Akıllı Sözleşmelerde token yetkilendirmesi için yaygın olarak kullanılan iki fonksiyonu tartışıyoruz: approve() ve permit().

Yaygın ERC20 sözleşmesinde, A Hesabı approve() fonksiyonunu çağırarak B Hesabına belirli miktarda token için yetki verebilir, böylece B Hesabı bu tokenleri A Hesabından transfer edebilir. Ayrıca, EIP-2612'de ERC20 sözleşmelerine permit() fonksiyonu eklenmiş ve Uniswap, Kasım 2022'de Permit2 adında yeni bir token yetkilendirme standardı yayınlamıştır.

Özel Mantık

İşte bir örnek. Bir gün Bill, bir blok zinciri haber sitesini gezinirken aniden bir Metamask imza popup'ı belirdi. Birçok blok zinciri web sitesi veya uygulaması kullanıcı girişlerini doğrulamak için imzalar kullandığından, Bill bunu çok önemsemedi ve imzayı doğrudan tamamladı. Beş dakika sonra, Metamask varlıkları boşaltıldı. Bill daha sonra blok zinciri gezgininde bilinmeyen bir adresin önce bir permit() işlemi, ardından cüzdanını boşaltan bir transferFrom() işlemi başlattığını keşfetti.

Örnek

İki fonksiyon aşağıdaki gibidir:

approve(): A Hesabının B Hesabına belirli miktarda fon yetkilendirdiği standart bir yetkilendirme fonksiyonu.
permit(): B Hesabının imza doğrulamasını gönderip tamamlayarak A Hesabından yetkilendirilmiş miktarı aldığı bir imza yetkilendirme fonksiyonu. Parametreler arasında yetki veren sahibi, yetkilendirilen harcayıcı, yetkilendirilen miktar, imza son tarihi ve sahibin imza verileri v, r ve s bulunur.

Çözümler

1. Blok zinciri etkileşimlerinde her imzaya dikkat edin

Bazı cüzdanların approve() yetkilendirme imza bilgilerini çözme ve görüntüleme konusunda aldığı önlemlere rağmen, permit() imza oltalama için neredeyse hiç uyarı sağlamamaları saldırı riskini artırmaktadır. Bu nedenle, bilinmeyen her imzanın permit() fonksiyonunu hedeflediğinden emin olmak için titizlikle incelenmesi şiddetle tavsiye edilir.

2. Düzenli etkileşim için kullanılan cüzdanı, varlıkları saklayan cüzdandan ayırın

Bu, özellikle her gün sayısız dApp veya web sitesiyle etkileşime giren ve tuzaklara düşmeye yatkın olan airdrop avcıları başta olmak üzere kripto kullanıcıları için son derece önemlidir. Düzenli etkileşim için kullanılan bir cüzdanda yalnızca küçük miktarda fon saklamak, kayıpları yönetilebilir bir aralıkta tutabilir.

7. Bal Küpü Saldırısı

Blok zinciri endüstrisinde, bal küpü saldırısı proje ekipleri tarafından dağıtılan kötü niyetli token sözleşmelerini ifade eder. Sözleşme yalnızca proje ekibine satış izni verirken, normal kullanıcılar yalnızca satın alabilir ancak satamaz ve böylece zarara uğrar.

Özel Mantık

İşte bir örnek. Telegram'daki bir duyuruda, Proje A kullanıcıları tokenin ana ağda dağıtıldığını ve alım satım için hazır olduğunu bilgilendirir. Token yalnızca satın alınabildiği ve satılamadığı için fiyat başlangıçta yükselmeye devam eder ve kaçırma korkusu yaşayan kullanıcılar satın almaya devam eder. Bir süre sonra kullanıcılar satamadıklarını fark ettiklerinde, proje ekibi bu fırsatı değerlendirir ve tokenleri boşaltır, bu da fiyatın düşmesine neden olur.

Örnek

Temel işlev:

_beforeTokenTransfer(): Token transferleri sırasında çağrılan ve yalnızca sahibi tarafından çağrıldığında başarılı olabilen dahili bir fonksiyon; diğer hesaplardan yapılan çağrılar başarısız olacaktır.

Çözüm

Güvenlik tarama araçlarını kullanın

a. Ethereum tokenleri için Token Sniffer

b. Diğer zincirlerdeki tokenler için Ave Check

c. Dextools gibi yerleşik algılama araçlarına sahip Ekinlik Piyasaları web siteleri

Düşük puanlı tokenlerle işlem yapmaktan kaçının.

8. Ön Koşma Saldırısı

Ön koşma, başlangıçta geleneksel finans piyasalarında ortaya çıktı; burada bilgi asimetrisi, finansal aracıların belirli sektör bilgilerine dayanarak hızlı eylemler gerçekleştirerek kâr elde etmesine olanak tanıyordu. Blockchain endüstrisinde, ön koşma esas olarak zincir üzerinde ön koşmadan kaynaklanır ve bu, madencilerin kendi işlemlerini zincire öncelikli olarak paketlemesini manipüle ederek kâr elde etmeyi içerir.

Blockchain alanında madenciler, bloklara paketledikleri işlemleri manipüle ederek kâr elde edebilirler, örneğin belirli işlemleri hariç tutarak ve işlemlerin sırasını değiştirerek. Bu tür kâr, Madenci Çıkarılabilir Değeri (MEV) ile ölçülebilir. Bir kullanıcının işlemi Ethereum ana ağına eklenmeden önce, işlemlerin çoğu mempool'da toplanır. Madenciler, kazançlarını en üst düzeye çıkarmak için bu mempool'da daha yüksek gas fiyatlarına sahip işlemleri arar ve bunları öncelikli olarak paketler. Genel olarak, daha yüksek gas fiyatlarına sahip işlemler madenciler tarafından daha kolay paketlenir. Bu arada, bazı MEV botları da kârlılık potansiyeli olan işlemler için mempool'u tararlar.

Özel Mantık

Aşağıda bir örnek verilmiştir. Bill, önemli fiyat dalgalanmaları olan yeni bir popüler token keşfeder. Uniswap'taki token işlemlerinin başarısını sağlamak için Bill, olağanüstü geniş bir kayma aralığı belirler. Ne yazık ki, Alice'in MEV botu bu işlemi mempool'da tespit eder ve hızla gas ücretini artırarak Bill'in işleminden önce bir satın alma işlemi başlatır ve aynı blok içinde Bill'in işleminden sonra bir satış işlemi ekler. Blok onayından sonra bu durum, Bill için önemli kayma kayıplarına neden olurken, Alice düşükten alıp yüksekten satma arbitrajı işleminden kâr elde eder.

Örnek

Fonksiyon aşağıdaki gibidir:

solve(): Herkesin bir cevap gönderebileceği bir tahmin fonksiyonudur ve eğer gönderilen cevap hedef cevapla eşleşirse, gönderen kişi 10 ether alabilir.

Süreç: Bill doğru cevabı bulur.
Alice, birinin doğru cevabı göndermesini bekleyerek mempool'u izler.
Bill, cevabı göndermek için solve() fonksiyonunu çağırır ve gaz fiyatını 100 Gwei olarak ayarlar.
Alice, Bill'in gönderdiği işlemi görür ve cevabı keşfeder. Bill'inkinden daha yüksek bir gaz fiyatı olan 200 Gwei'yi ayarlar ve solve() fonksiyonunu çağırır.
Alice'in işlemi, Bill'inkinden önce madenci tarafından paketlenir.
Alice 10 ether ödül kazanır.

Çözüm

Üç ana fonksiyon aşağıdaki gibidir:

commitSolution(): Sonuçları göndermek için bir fonksiyon, kullanıcının gönderdiği cevap solutionHash, gönderim zamanı commitTime ve durumu revealed'ı Commit yapısına yerleştirir.
getMySolution(): Sonuçları elde etmek için bir fonksiyon, kullanıcıların gönderdiği cevapları ve ilgili bilgileri görüntülemelerine olanak tanır, kullanıcının gönderdiği cevap solutionHash, gönderim zamanı commitTime ve durumu revealed dahil.
revealSolution(): Bulmacayı tahmin etmek için ödülleri talep etme fonksiyonu, kullanıcıların cevabı ve ayarladıkları şifreyi sağladıktan sonra ödülleri talep etmelerine olanak tanır.

Süreç:

Bill doğru cevabı bulur.
Bill, doğru cevabı göndermek için commitSolution() fonksiyonunu çağırır.
Bir sonraki blokta Bill, ödülü talep etmek için belirlediği cevabı ve şifreyi sağlayarak revealSolution() fonksiyonunu çağırır.

commitSolution() fonksiyonunda Bill, şifrelenmiş bir dize gönderir ve düz metin verisini yalnızca kendisine saklar. Bu adımda, gönderimin blok zamanı olan commitTime de kaydedilir. Ardından, revealSolution() fonksiyonunda, aynı blok içinde ön sıralama yapılmasını önlemek için blok zamanı kontrol edilir. revealSolution() fonksiyonunun çağrılması düz metin cevabının gönderilmesini gerektirdiğinden, bu adım başkalarının commitSolution() fonksiyonunu atlayıp doğrudan revealSolution() fonksiyonunu çağırmasını engellemeyi amaçlar. Başarılı doğrulama sonrasında, cevap doğru olarak kontrol edilirse ödül dağıtılacaktır.

Sonuç

Akıllı sözleşmeler, blok zinciri teknolojisinde çok önemli bir rol oynamakta ve çok sayıda avantaj sunmaktadır. İlk olarak, merkezi olmayan, otomatik yürütmeyi mümkün kılarak, üçüncü taraflara ihtiyaç duymadan işlem güvenliğini ve güvenilirliğini sağlarlar. İkincisi, akıllı sözleşmeler aracı adımları ve maliyetleri azaltarak işlem verimliliğini artırır.

Bu kadar çok fayda sağlamalarına rağmen, akıllı sözleşmeler aynı zamanda kullanıcılara finansal kayıplar yaşatabilecek saldırı riskiyle de karşı karşıyadır. Bu nedenle, zincir üzerindeki kullanıcılar için bazı alışkanlıklar esastır. İlk olarak, kullanıcılar her zaman etkileşime girecekleri dApp'leri dikkatle seçmeli ve sözleşme kodunu ve ilgili kuralları detaylı bir şekilde incelemelidir. Ek olarak, hacker saldırılarının riskini azaltmak için güvenli cüzdanları ve sözleşme etkileşim araçlarını düzenli olarak güncellemeli ve kullanmalıdırlar. Ayrıca, sözleşme saldırılarından kaynaklanabilecek potansiyel kayıpları en aza indirmek için fonlarını birden fazla adreste saklamaları tavsiye edilir.

Endüstri oyuncuları için, akıllı sözleşmelerin güvenliğini ve istikrarını sağlamak eşit derecede önemlidir. İlk öncelik, potansiyel açıkları ve güvenlik risklerini tespit etmek ve düzeltmek için akıllı sözleşmelerin denetimini güçlendirmek olmalıdır. İkinci olarak, endüstri oyuncuları sözleşme saldırılarıyla ilgili en son blok zinciri gelişmelerinden haberdar olmalı ve buna göre güvenlik önlemleri almalıdır. Son olarak, akıllı sözleşmelerin doğru kullanımı konusunda kullanıcı eğitimini ve güvenlik farkındalığını da artırmalıdırlar.

Sonuç olarak, hem kullanıcıların hem de endüstri oyuncularının ortak çabalarıyla, akıllı sözleşmelerin oluşturduğu güvenlik riskleri önemli ölçüde azaltılabilir. Kullanıcılar her zaman sözleşmeleri dikkatle seçmeli ve kişisel varlıklarını korumalı, endüstri oyuncuları ise sözleşme denetimini yoğunlaştırmalı, teknolojik gelişmeleri takip etmeli ve kullanıcı eğitimini ve güvenlik farkındalığını artırmalıdır. Birlikte, akıllı sözleşmelerin güvenli ve güvenilir gelişimini sağlayacağız.

Kaynaklar:

Solidity Örneği：https://solidity-by-example.org/

SlowMist'in Blok Zinciri Bilgisi：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - En İyi 10 DeFi Güvenlik Uygulaması：https://blog.chain.link/defi-security-best-practices/#post-title

WTF - Solidity 104 Sözleşme Güvenliği：https://www.wtf.academy/solidity-104/

38 Senaryoda 4 Kategoride DeFi Akıllı Sözleşmelerindeki Güvenlik Açıkları：https://www.weiyangx.com/381670.html

OpenZeppelin：https://github.com/OpenZeppelin/

Akıllı Sözleşmelerde Yaygın Güvenlik Açıkları ve Saldırılara Giriş