blog 1HaberlerGeliştiricilerEnterpriseBlockchain AçıklamasıEtkinlikler ve KonferanslarBasınBültenler

Contents

Haber bültenimize abone ol.

E

Senin gizliliğine saygı duyuyoruz

AnasayfaBlogBlockchain Geliştirme

Akıllı Sözleşme Güvenliği için En İyi Sağlamlık Uygulamaları

İzlemeden zaman damgası ile ilgili hususlara kadar, Ethereum akıllı sözleşmelerinizin güçlendirilmesini sağlamak için bazı profesyonel ipuçları. by ConsenSysAğustos 21, 2020Yayınlanan Ağustos 21, 2020

sağlamlık en iyi uygulamalar kahramanı


Blockchain güvenlik uzmanlarından oluşan ekibimiz ConsenSys Diligence tarafından.

Akıllı sözleşme güvenlik zihniyetini kalbine aldıysanız ve EVM’nin kendine özgü özelliklerini ele alıyorsanız, Solidity programlama diline özgü bazı güvenlik modellerini göz önünde bulundurmanın zamanı geldi. Bu derlemede, Solidity için diğer dillerde akıllı sözleşmeler geliştirmek için öğretici olabilecek güvenli geliştirme önerilerine odaklanacağız.. 

Tamam, atlayalım.

Doğru şekilde assert (), require (), revert () kullanın

Rahatlık fonksiyonları iddia etmek ve gerek koşulları kontrol etmek ve koşul karşılanmazsa bir istisna atmak için kullanılabilir.

 iddia etmek işlevi yalnızca dahili hataları test etmek ve değişmezleri kontrol etmek için kullanılmalıdır.

 gerek işlev, girdiler veya sözleşme durumu değişkenleri gibi geçerli koşulların karşılandığından emin olmak veya harici sözleşmelere yapılan çağrılardan dönüş değerlerini doğrulamak için kullanılmalıdır.. 

Bu paradigmanın izlenmesi, resmi analiz araçlarının geçersiz işlem koduna asla ulaşılamayacağını doğrulamasına izin verir: bu, koddaki hiçbir değişmezin ihlal edilmediği ve kodun resmi olarak doğrulandığı anlamına gelir..

pragma sağlamlığı ^ 0.5.0; sözleşme Paylaşan {function sendHalf (ödenecek adres) kamu ödenecek iadeler (uint bakiyesi) {require (msg.value% 2 == 0, "Eşit değer gerekli."); // Require () isteğe bağlı bir mesaj dizesine sahip olabilir uint balanceBeforeTransfer = adres (bu) .balance; (bool başarısı,) = addr.call.value (msg.value / 2) (""); gerektirir (başarı); // Transfer başarısız olursa geri döndüğümüzden, // paranın yarısına sahip olmamıza imkan olmamalı. assert (adres (bu) .balance == balanceBeforeTransfer – msg.value / 2); // dönüş adresi (bu) .balance; }} Kod dili: JavaScript (javascript)

Görmek SWC-110 & SWC-123

Değiştiricileri yalnızca kontroller için kullanın

Bir değiştiricinin içindeki kod genellikle işlev gövdesinden önce yürütülür, bu nedenle herhangi bir durum değişikliği veya harici çağrı, Kontroller-Etkiler-Etkileşimler Desen. Dahası, bu ifadeler geliştirici tarafından fark edilmeden kalabilir, çünkü değiştirici kodu işlev bildiriminden uzak olabilir. Örneğin, değiştiricide harici bir çağrı, yeniden giriş saldırısına yol açabilir:

sözleşme Kayıt {adres sahibi; function isVoter (address _addr) harici dönüşler (bool) {// Code}} contract Election {Registry Registry; değiştirici isEligible (adres _addr) {gerektirir (kayıt.isVoter (_addr)); _; } function vot () isEligible (msg.sender) public {// Code}} Kod dili: JavaScript (javascript)

Bu durumda, Tescil sözleşmesi, isVoter () içindeki Election.vote () öğesini çağırarak bir yeniden giriş saldırısı yapabilir..

Not: Kullanım değiştiriciler isOwner () gibi birden çok işlevde yinelenen koşul denetimlerini değiştirmek için, aksi takdirde işlevin içinde gereksinim veya geri dönme işlevini kullanın. Bu, akıllı sözleşme kodunuzu daha okunabilir ve denetlemesi daha kolay hale getirir.

Tamsayı bölmeli yuvarlamaya dikkat edin

Tüm tamsayı bölmeleri en yakın tam sayıya aşağı yuvarlanır. Daha fazla hassasiyete ihtiyacınız varsa, bir çarpan kullanmayı düşünün veya hem payı hem de paydayı saklayın.

(Gelecekte, Solidity’nin bir sabit nokta yazın, bu da bunu kolaylaştıracaktır.)

// kötü uint x = 5/2; // Sonuç 2’dir, tüm tamsayı bölmeleri AŞAĞI en yakın integerCode diline yuvarlar: JavaScript (javascript)

Bir çarpan kullanmak yuvarlamayı önler, bu çarpanın gelecekte x ile çalışırken hesaba katılması gerekir:

// iyi uint çarpanı = 10; uint x = (5 * çarpan) / 2; Kod dili: JavaScript (javascript)

Pay ve paydanın saklanması, zincir dışı pay / paydanın sonucunu hesaplayabileceğiniz anlamına gelir:

// iyi uint payı = 5; uint payda = 2; Kod dili: JavaScript (javascript)

Arasındaki değiş tokuşların farkında olun soyut sözleşmeler ve arayüzler

Hem arayüzler hem de soyut sözleşmeler, akıllı sözleşmeler için özelleştirilebilir ve yeniden kullanılabilir bir yaklaşım sağlar. Solidity 0.4.11’de tanıtılan arayüzler soyut sözleşmelere benzer ancak herhangi bir işlevi uygulanamaz. Arayüzlerin ayrıca depolamaya erişememe veya diğer arayüzlerden devralamama gibi sınırlamaları da vardır, bu da genellikle soyut sözleşmeleri daha pratik hale getirir. Bununla birlikte, arayüzler, uygulamadan önce sözleşmelerin tasarlanması için kesinlikle yararlıdır. Ek olarak, bir sözleşme soyut bir sözleşmeden miras alıyorsa, uygulanmayan tüm işlevleri geçersiz kılma yoluyla uygulaması gerektiğini veya aynı zamanda soyut olacağını akılda tutmak önemlidir..

Geri dönüş işlevleri

Geri dönüş işlevlerini basit tutun

Geri dönüş işlevleri bir sözleşme argümansız bir mesaj gönderildiğinde (veya hiçbir işlev eşleşmediğinde) çağrıldığında ve yalnızca .send () veya .transfer () ‘den çağrıldığında 2.300 gaza erişime sahip olduğunda çağrılır. Bir .send () veya .transfer () ‘den Ether alabilmek istiyorsanız, bir geri dönüş işlevinde yapabileceğiniz en fazla şey bir olayı günlüğe kaydetmektir. Daha fazla gazın hesaplanması gerekiyorsa uygun bir işlevi kullanın.

// bozuk işlev () ödenebilir {bakiyeler [msg.sender] + = msg.value; } // iyi işlev depozitosu () ödenebilir harici {bakiyeler [msg.sender] + = msg.value; } ödenecek işlev () {require (msg.data.length == 0); emit LogDepositReceived (msg.sender); } Kod dili: JavaScript (javascript)

Geri dönüş işlevlerinde veri uzunluğunu kontrol edin

Beri geri dönüş işlevleri sadece düz eter transferleri için değil (veri olmadan), aynı zamanda başka hiçbir işlev eşleşmediğinde, geri dönüş işlevinin yalnızca alınan Ether’i günlüğe kaydetme amacıyla kullanılması amaçlanıyorsa verilerin boş olup olmadığını kontrol etmelisiniz. Aksi takdirde, arayanlar sözleşmenizin yanlış kullanılıp kullanılmadığını fark etmeyecek ve mevcut olmayan fonksiyonlar aranacaktır..

// kötü işlev () ödenebilir {emit LogDepositReceived (msg.sender); } // iyi işlev () ödenebilir {required (msg.data.length == 0); emit LogDepositReceived (msg.sender); } Kod dili: JavaScript (javascript)

Ödenecek işlevleri ve durum değişkenlerini açıkça işaretleyin

Solidity 0.4.0’dan başlayarak, ether alan her işlevin ödenebilir değiştirici kullanması gerekir, aksi takdirde işlemde msg.value varsa > 0 geri dönecek (zorlanmadıkça).

Not: Açık olmayabilecek bir şey: Ödenecek değiştirici yalnızca harici sözleşmelerden gelen aramalar için geçerlidir. Aynı sözleşmede ödenebilir işlevde bir ödenemez işlevi çağırırsam, msg.value hala ayarlanmış olsa da ödenemez işlev başarısız olmaz.

İşlevlerde ve durum değişkenlerinde görünürlüğü açıkça işaretleyin

Fonksiyonların ve durum değişkenlerinin görünürlüğünü açıkça etiketleyin. Fonksiyonlar harici, genel, dahili veya özel olarak belirtilebilir. Lütfen aralarındaki farkları anlayın, örneğin, genel yerine harici yeterli olabilir. Durum değişkenleri için harici mümkün değildir. Görünürlüğün açıkça etiketlenmesi, işlevi kimin çağırabileceği veya değişkene kimin erişebileceği hakkında yanlış varsayımların yakalanmasını kolaylaştıracaktır..

  • Harici işlevler, sözleşme arayüzünün bir parçasıdır. Harici bir fonksiyon f dahili olarak çağrılamaz (yani f () çalışmaz, ancak bu f () çalışır). Dış işlevler bazen büyük veri dizileri aldıklarında daha etkilidir.
  • Genel işlevler, sözleşme arayüzünün bir parçasıdır ve dahili olarak veya mesajlar aracılığıyla çağrılabilir. Genel durum değişkenleri için, otomatik bir alıcı işlevi (aşağıya bakın) oluşturulur.
  • Dahili işlevlere ve durum değişkenlerine, bunu kullanmadan yalnızca dahili olarak erişilebilir.
  • Özel işlevler ve durum değişkenleri, türetilmiş sözleşmelerde değil, yalnızca tanımlandıkları sözleşmeler için görülebilir.. Not: Bir sözleşmenin içindeki her şey, özel değişkenler dahil olmak üzere, blok zincirinin dışındaki tüm gözlemciler tarafından görülebilir..

// kötü uint x; // varsayılan, durum değişkenleri için dahilidir, ancak açıkça belirtilmelidir işlev buy () {// varsayılan geneldir // genel kod} // iyi uint özel y; function buy () external {// yalnızca harici olarak çağrılabilir veya this.buy ()} işlevi yardımcı programını () public {// harici olarak ve dahili olarak kullanarak: Bu kodu değiştirmek, her iki durumu da düşünmeyi gerektirir. } function internalAction () dahili {// dahili kod} Kod dili: PHP (php)

Görmek SWC-100 ve SWC-108

Pragmaları belirli derleyici sürümüne kilitleyin

Sözleşmeler, en çok test edildikleri aynı derleyici sürümü ve bayrakları ile dağıtılmalıdır. Pragmanın kilitlenmesi, sözleşmelerin, örneğin keşfedilmemiş hata riskleri daha yüksek olabilecek en son derleyici kullanılarak yanlışlıkla dağıtılmamasını sağlamaya yardımcı olur. Sözleşmeler başkaları tarafından da dağıtılabilir ve pragma, orijinal yazarlar tarafından tasarlanan derleyici sürümünü gösterir..

// kötü pragma sağlamlığı ^ 0.4.4; // iyi pragma sağlamlığı 0.4.4; Kod dili: JavaScript (javascript)

Not: yüzen bir pragma sürümü (yani. ^ 0.4.25), 0.4.26-nightly.2018.9.25 ile iyi bir şekilde derleyecektir, ancak gecelik yapılar asla üretim için kod derlemek için kullanılmamalıdır..

Uyarı: Bir kitaplık veya EthPM paketindeki sözleşmelerde olduğu gibi, bir sözleşmenin diğer geliştiriciler tarafından tüketilmesi amaçlandığında Pragma ifadelerinin yüzmesine izin verilebilir. Aksi takdirde, geliştiricinin yerel olarak derlemek için pragmayı manuel olarak güncellemesi gerekir..

Görmek SWC-103

Sözleşme etkinliğini izlemek için olayları kullanın

Dağıtıldıktan sonra sözleşmenin etkinliğini izlemek için bir yönteme sahip olmak faydalı olabilir. Bunu başarmanın bir yolu, sözleşmenin tüm işlemlerine bakmaktır, ancak bu, sözleşmeler arasındaki mesaj çağrıları blok zincirine kaydedilmediği için yetersiz olabilir. Ayrıca, durumda yapılan fiili değişiklikleri değil, yalnızca giriş parametrelerini gösterir. Ayrıca olaylar, kullanıcı arayüzündeki işlevleri tetiklemek için kullanılabilir.

Contract Charity {eşleme (adres => uint) bakiyeleri; function donate () ödenebilir genel {bakiyeler [msg.sender] + = msg.value; }} Contract Game {function buyCoins () payable public {// 5% charity charity.donate.value (msg.value / 20) (); }} Kod dili: JavaScript (javascript)

Burada, Oyun sözleşmesi, Charity.donate () ‘e dahili bir çağrı yapacak. Bu işlem, Hayır Kurumunun harici işlem listesinde görünmeyecek, ancak yalnızca dahili işlemlerde görülebilir.

Bir olay, sözleşmede olan bir şeyi günlüğe kaydetmenin uygun bir yoludur. Yayılan olaylar, diğer sözleşme verileriyle birlikte blok zincirinde kalır ve gelecekteki denetimler için kullanılabilir. Vakfın bağışlarının geçmişini sağlamak için etkinlikleri kullanarak yukarıdaki örnekte bir iyileştirme aşağıda verilmiştir..

Contract Charity {// olay olayını tanımlayın LogDonate (uint _amount); eşleme (adres => uint) bakiyeleri; function donate () ödenebilir genel {bakiyeler [msg.sender] + = msg.value; // olay emit LogDonate (msg.value); }} Contract Game {function buyCoins () payable public {// 5% charity charity.donate.value (msg.value / 20) (); }} Kod dili: JavaScript (javascript)

Burada, hayır kurumu sözleşmesinden geçen tüm işlemler, ister doğrudan ister değil, bağışlanan para miktarı ile birlikte o sözleşmenin olay listesinde görünecektir..

Not: Daha yeni Solidity yapılarını tercih edin. Kendi kendine zarar (intihar yerine) ve keccak256 (sha3’ün üzerinde) gibi yapıları / takma adları tercih edin. Require (msg.sender.send (1 ether)) gibi modeller msg.sender.transfer (1 ether) ‘de olduğu gibi transfer () kullanılarak basitleştirilebilir. Ödeme Sağlamlık Değişikliği günlüğü daha benzer değişiklikler için.

“Yerleşiklerin” gölgelenebileceğini unutmayın

Şu anda mümkündür gölge Solidity’de yerleşik globaller. Bu, sözleşmelerin msg ve revert () gibi yerleşiklerin işlevselliğini geçersiz kılmasına izin verir. Buna rağmen amaçlanmıştır, Kullanıcıları, sözleşmenin gerçek davranışına göre yanıltabilir.

sözleşme PretendingToRevert {function revert () dahili sabit {}} contract ExampleContract is PretendingToRevert {function somethingBad () public {revert (); }}

Sözleşme kullanıcıları (ve denetçiler), kullanmayı düşündükleri herhangi bir uygulamanın tam akıllı sözleşme kaynak kodunun farkında olmalıdır..

Tx.origin kullanmaktan kaçının

Asla tx.origin’i yetkilendirme için kullanmayın, başka bir sözleşmede sözleşmenizi çağıracak bir yöntem olabilir (örneğin, kullanıcının bir miktar parası olduğu durumlarda) ve adresiniz tx.origin’de olduğu için sözleşmeniz bu işlemi yetkilendirir..

sözleşme MyContract {adres sahibi; function MyContract () public {owner = msg.sender; } function sendTo (adres alıcısı, uint miktarı) public {required (tx.origin == owner); (bool başarısı,) = alıcı.call.value (miktar) (""); gerektirir (başarı); }} contract AttackingContract {MyContract myContract; adres saldırganı; function AttackingContract (adres myContractAddress) public {myContract = MyContract (myContractAddress); saldırgan = msg.sender; } function () public {myContract.sendTo (saldırgan, msg.sender.balance); }} Kod dili: JavaScript (javascript)

Yetkilendirme için msg.sender kullanmalısınız (başka bir sözleşme sözleşmenizi ararsa, msg.sender sözleşmeyi arayan kullanıcının adresi değil sözleşmenin adresi olacaktır).

Bununla ilgili daha fazla bilgiyi buradan okuyabilirsiniz: Solidity belgeleri

Uyarı: Yetkilendirmeyle ilgili sorunun yanı sıra, gelecekte tx.origin’in Ethereum protokolünden kaldırılma ihtimali vardır, bu nedenle tx.origin kullanan kod gelecekteki sürümlerle uyumlu olmayacaktır. Vitalik: “tx.origin’in kullanılabilir veya anlamlı olmaya devam edeceğini varsaymayın.”

Ayrıca tx.origin’i kullanarak, sözleşmeler arasındaki birlikte çalışabilirliği sınırlamış oluyorsunuz çünkü tx.origin kullanan sözleşme, bir sözleşme tx.origin olamayacağı için başka bir sözleşme tarafından kullanılamaz..

Görmek SWC-115

Zaman damgası bağımlılığı

Bir sözleşmedeki kritik bir işlevi yürütmek için bir zaman damgası kullanırken, özellikle de fon transferini içeren eylemler olduğunda, dikkate alınması gereken üç ana husus vardır..

Zaman damgası manipülasyonu

Bloğun zaman damgasının bir madenci tarafından değiştirilebileceğini unutmayın. Bunu düşün sözleşme:

uint256 sabit özel tuz = block.timestamp; fonksiyon rastgele (uint Max) sabit özel döner (uint256 sonucu) {// rastgelelik için en iyi tohumu elde edin uint256 x = salt * 100 / Max; uint256 y = tuz * blok.numarası / (tuz% 5); uint256 tohum = blok.numarası / 3 + (tuz% 300) + Son_ayout + y; uint256 h = uint256 (block.blockhash (tohum)); dönüş uint256 ((h / x))% Max + 1; // 1 ile Maks arasında rastgele sayı} Kod dili: PHP (php)

Kontrat rastgele bir sayıyı tohumlamak için zaman damgasını kullandığında, madenci aslında bloğun doğrulanmasından sonraki 15 saniye içinde bir zaman damgası gönderebilir ve böylece madencinin piyangodaki şanslarına daha uygun bir seçeneği önceden hesaplamasına etkili bir şekilde izin verir. Zaman damgaları rastgele değildir ve bu bağlamda kullanılmamalıdır.

15 saniye Kuralı

 Sarı Kağıt (Ethereum’un referans spesifikasyonu), zaman içinde ne kadar bloğun sürüklenebileceğine dair bir kısıtlama belirtmez, ancak belirtiyor her zaman damgasının, üst öğesinin zaman damgasından daha büyük olması gerekir. Popüler Ethereum protokol uygulamaları Geth ve Parite her ikisi de gelecekte 15 saniyeden fazla zaman damgasına sahip blokları reddeder. Bu nedenle, zaman damgası kullanımını değerlendirmenin iyi bir kuralı şudur: zamana bağlı etkinliğinizin ölçeği 15 saniye değişebiliyorsa ve bütünlüğü koruyabiliyorsa, bir blok kullanmak güvenlidir. Timestamp.

Block.number’ı bir zaman damgası olarak kullanmaktan kaçının

Block.number özelliğini kullanarak bir zaman delta tahmin etmek mümkündür ve ortalama blok süresi, ancak bu, blok süreleri değişebileceğinden (örneğin çatal yeniden düzenlemeleri ve zorluk bombası). Günleri kapsayan bir satışta, 15 saniye kuralı, bir kişinin daha güvenilir bir zaman tahmini elde etmesini sağlar.

Görmek SWC-116

Çoklu kalıtım uyarısı

Solidity’de çoklu kalıtım kullanırken, derleyicinin kalıtım grafiğini nasıl oluşturduğunu anlamak önemlidir..

sözleşme Nihai {uint public a; function Son (uint f) public {a = f; }} sözleşme B Nihai {int kamu ücreti; işlev B (uint f) Son (f) genel {} işlev setFee () genel {ücret = 3; }} sözleşme C Nihai {int kamu ücreti; işlev C (uint f) Son (f) genel {} işlev setFee () genel {ücret = 5; }} sözleşme A, B’dir, C {işlev A () genel B (3) C (5) {setFee (); }} Kod dili: PHP (php)

Bir sözleşme dağıtıldığında, derleyici kalıtımı sağdan sola doğru doğrusallaştırır (anahtar sözcük olduktan sonra üstler en temelden en çok türetilene doğru listelenir). Sözleşme A’nın doğrusallaştırması şöyledir:

Final <- B <- C <- Bir

Doğrusallaştırmanın sonucu, C en çok türetilmiş sözleşme olduğundan 5’lik bir ücret değeri verecektir. Bu açık görünebilir, ancak C’nin önemli işlevleri gölgeleyebildiği, boole cümleciklerini yeniden sıralayabildiği ve geliştiricinin istismar edilebilir sözleşmeler yazmasına neden olduğu senaryolar hayal edin. Statik analiz şu anda gölgede kalan işlevlerle ilgili sorun yaratmamaktadır, bu nedenle manuel olarak incelenmesi gerekir.

Katkıda bulunmaya yardımcı olmak için Solidity’den Github’ın proje mirasla ilgili tüm sorunlar ile.

Görmek SWC-125

Tip güvenliği için adres yerine arayüz tipini kullanın

Bir işlev bağımsız değişken olarak bir sözleşme adresini aldığında, ham adres yerine bir arabirim veya sözleşme türünü iletmek daha iyidir. İşlev, kaynak kod içinde başka bir yerde çağrılırsa, derleyici ek tür güvenlik garantileri sağlayacaktır..

Burada iki alternatif görüyoruz:

sözleşme Doğrulayıcı {function validate (uint) harici dönüşler (bool); } sözleşme TypeSafeAuction {// iyi işlev validateBet (Validator _validator, uint _value) dahili dönüşler (bool) {bool valid = _validator.validate (_value); geçerli dönüş; }} contract TypeUnsafeAuction {// kötü işlev validateBet (adres _addr, uint _value) dahili dönüşler (bool) {Doğrulayıcı doğrulayıcı = Doğrulayıcı (_addr); bool geçerli = validator.validate (_value); geçerli dönüş; }} Kod dili: JavaScript (javascript)

Yukarıdaki TypeSafeAuction sözleşmesini kullanmanın faydaları aşağıdaki örnekten görülebilir. ValidateBet () bir adres bağımsız değişkeni veya Validator dışında bir sözleşme türü ile çağrılırsa, derleyici şu hatayı atar:

sözleşmeli NonValidator {} sözleşmeli Açık Artırma TypeSafeAuction’dır {NonValidator nonValidator; function bet (uint _value) {bool valid = validateBet (nonValidator, _value); // TypeError: İşlev çağrısında bağımsız değişken için geçersiz tür. // NonValidator sözleşmesinden // sözleşme Doğrulayıcıya geçersiz örtük dönüştürme istendi. }} Kod dili: JavaScript (javascript)

Harici olarak sahip olunan hesapları kontrol etmek için extcodesize kullanmaktan kaçının

Aşağıdaki değiştirici (veya benzer bir kontrol) genellikle bir aramanın harici olarak sahip olunan bir hesaptan (EOA) veya bir sözleşme hesabından yapılıp yapılmadığını doğrulamak için kullanılır:

// hatalı değiştirici isNotContract (adres _a) {uint boyut; montaj {size: = extcodesize (_a)} gerektirir (size == 0); _; } Kod dili: JavaScript (javascript)

Fikir açıktır: Bir adres kod içeriyorsa, bu bir EOA değil, sözleşmeli bir hesaptır. ancak, bir sözleşmenin inşaat sırasında mevcut kaynak kodu yoktur. Bu, kurucu çalışırken diğer sözleşmelere çağrı yapabileceği, ancak adresi için extcodesize’ın sıfır döndürdüğü anlamına gelir. Aşağıda, bu kontrolün nasıl atlatılabileceğini gösteren minimal bir örnek bulunmaktadır:

sözleşme OnlyForEOA {uint public flag; // kötü değiştirici isNotContract (adres _a) {uint len; derleme {len: = extcodesize (_a)} gerektirir (len == 0); _; } işlev setFlag (uint i) public isNotContract (msg.sender) {bayrak = i; }} sözleşme FakeEOA {yapıcı (adres _a) genel {OnlyForEOA c = OnlyForEOA (_a); c.setFlag (1); }} Kod dili: JavaScript (javascript)

Sözleşme adresleri önceden hesaplanabildiğinden, bu kontrol, n bloğunda boş olan, ancak n’den büyük bir blokta kendisine dağıtılan bir sözleşmeye sahip olan bir adresi kontrol ederse de başarısız olabilir..

Uyarı: Bu sorun inceliklidir. Amacınız diğer sözleşmelerin sözleşmenizi çağırmasını engellemekse, dış kod boyutu kontrolü muhtemelen yeterlidir. Alternatif bir yaklaşım, (tx.origin == msg.sender) değerini kontrol etmektir, ancak bu aynı zamanda sakıncaları var.

Dış kodlama kontrolünün amacınıza hizmet ettiği başka durumlar da olabilir. Hepsini burada açıklamak kapsam dışıdır. EVM’nin altında yatan davranışları anlayın ve kararınızı kullanın.

Blockchain Kodunuz Güvenli mi?

Güvenlik uzmanlarımızdan 1 günlük yerinde kontrol için rezervasyon yapın. Bugün Sevdiklerinizi Ayırtın DiligenceGüvenlikAkıllı SözleşmelerSolidityHaber Bülteni En son Ethereum haberleri, kurumsal çözümler, geliştirici kaynakları ve daha fazlası için haber bültenimize abone olun.Başarılı Bir Blockchain Ürünü Nasıl OluşturulurWeb semineri

Başarılı Bir Blockchain Ürünü Nasıl Oluşturulur

Ethereum Düğümü Nasıl Kurulur ve ÇalıştırılırWeb semineri

Ethereum Düğümü Nasıl Kurulur ve Çalıştırılır

Kendi Ethereum API'nizi Nasıl Oluşturabilirsiniz?Web semineri

Kendi Ethereum API’nizi Nasıl Oluşturabilirsiniz?

Sosyal Simge Nasıl OluşturulurWeb semineri

Sosyal Simge Nasıl Oluşturulur

Akıllı Sözleşme Geliştirmede Güvenlik Araçlarını KullanmaWeb semineri

Akıllı Sözleşme Geliştirmede Güvenlik Araçlarını Kullanma

Finansın Geleceği Dijital Varlıklar ve DeFiWeb semineri

Finansın Geleceği: Dijital Varlıklar ve DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me