Gizli Sahip Ayrıcalıkları: 'Doğrulanmış' Sözleşmelerdeki Tehlikeli Yönetici Fonksiyonları
— By Tony Rabbit in Tutorials

Doğrulanmış kaynak kodu, bir token'ın güvenli olduğu anlamına gelmez. Herhangi bir sözleşmenin Yazma fonksiyonu listesini nasıl denetleyeceğinizi, blacklist() ve pause() gibi yalnızca sahibine özel ayrıcalıkları nasıl tespit edeceğinizi ve zararsız yönetici araçlarını yatırımcıları tuzağa düşüren arka kapılardan nasıl ayıracağınızı öğrenin.
Akıllı bir sözleşmedeki gizli sahip ayrıcalıkları, bir token dağıtıcısının siz zaten satın aldıktan sonra kuralları değiştirmesine olanak tanıyan yalnızca yöneticiye özel fonksiyonlardır ve bir blok gezgininde tamamen temiz görünen sözleşmelerde rutin olarak varlıklarını sürdürürler. Tehlikeli kısım, kaynak kodu doğrulamasının yalnızca yayınlanan kodun zincir üzerindeki bayt koduyla eşleştiğini kanıtlamasıdır. Bu kodun ne yapmasına izin verildiği hakkında hiçbir şey söylemez. Bir sözleşme doğrulanmış, denetlenmiş ve hatta kısmen feragat edilmiş olsa bile, sahibinin cüzdanınızı dondurmasına, satışlarınızı kısıtlamasına veya hiç yoktan yeni arz basmasına izin veren bir fonksiyonu hala taşıyabilir. Bu rehber bir sözlük değil, uygulamalı bir denetimdir. Tam olarak hangi fonksiyonları arayacağınızı, bunları gezginde nasıl okuyacağınızı ve rutin yönetici araçlarını bir tuzaktan nasıl ayıracağınızı öğreneceksiniz.
Temel Çıkarımlar
- Doğrulama, kodun bayt koduyla eşleştiğini kanıtlar, kodun güvenli olduğunu değil.
- blacklist(), pause() ve ticaret geçişleri satış emirlerinizi kalıcı olarak dondurabilir.
- Bir mint arka kapısı, bir geliştiricinin likidite havuzuna hiç dokunmadan yatırımcıları seyreltmesini sağlar.
- Gezgindeki Yazma sekmesini okuyun ve fonksiyonları kimin çağırabileceğine ve neyi değiştirdiklerine göre değerlendirin.
Doğrulanmış veya kısmen feragat edilmiş bir sözleşme neden hala tehlikeli olabilir?
Doğrulama bir şeffaflık özelliğidir, bir güvenlik mührü değil. Bir proje sözleşmesini doğruladığında, gezgin gönderilen kaynağı derler ve zaten dağıtılmış olan tam bayt kodunu ürettiğini onaylar. Bu gerçekten faydalıdır çünkü onaltılık sayılara bakmak yerine sözleşmenin ne yaptığını okumanızı sağlar. Ancak kötü niyetli bir geliştirici de doğrulama ister, çünkü temiz, okunabilir bir sözleşme doğrulanmamış bir sözleşmeden daha hızlı güven oluşturur. Birçok dolandırıcılık, kasıtlı olarak doğrulanmış kod gönderir. Bu ayrımı netleştiremiyorsanız, doğrulanmış bir sözleşmenin aslında ne anlama geldiğine dair açıklayıcımız sınırlamaları ayrıntılı olarak ele almaktadır.
Sahiplikten feragat etmenin benzer bir boşluğu vardır. Bir geliştirici standart sahip rolünden feragat edebilir ve yine de mantığa sabit kodlanmış ikinci bir ayrıcalıklı adresi tutabilir veya tehlikeli ayarlayıcılar zaten hasarlarını verdikten sonra feragat edebilir. Feragat, riskli fonksiyon herkes tarafından çağrılabilir şekilde yazılmışsa veya ilk etapta sahiplik arkasına gizlenmemişse de hiçbir işe yaramaz. Feragatı bir yeşil ışık olarak görmeden önce feragat edilmiş bir sözleşmenin gerçekten neyi kanıtladığına dair analizimizi okuyun. Dürüst özet: doğrulanmış artı feragat edilmiş bir başlangıç noktasıdır, bir karar değil.
Akıllı bir sözleşmede aranacak gizli sahip ayrıcalıkları
Yatırımcıları tuzağa düşüren gücün çoğu, birkaç yalnızca sahibine özel fonksiyonda bulunur. Bu isimleri öğrenin ve bir sözleşmeyi bir iki dakika içinde tarayabilirsiniz. Geliştiricilerin bunları sık sık yeniden adlandırdığını unutmayın, bu yüzden sadece etikete göre değil, davranışa göre yargılayın.
- blacklist() / setBlacklist() / addBot() belirli cüzdanları işaretleyerek transfer veya satış yapmalarını engeller. Bir geliştirici, alıcıları girdikten hemen sonra kara listeye alabilir ve onları asla boşaltamayacakları token'larla bırakabilir.
- setMaxTx() / setMaxWallet() tek bir işlemde ne kadar hareket ettirebileceğinizi sınırlar. Çok küçük bir değere ayarlandığında, anlamlı satışları imkansız hale getirirken alımlar akmaya devam eder.
- enableTrading() / setTradingEnabled() transferlerin çalışıp çalışmadığını değiştirir. Eğer ticaret lansmandan sonra kapatılabiliyorsa, çıkışınız istenildiği zaman kapatılabilir.
- mint() veya arzı artıran herhangi bir fonksiyon, her yatırımcıyı seyreltmek için bir arka kapıdır. Bir geliştirici, likiditeyi hiç çekmeden değeri bu şekilde boşaltabilir.
- pause() / unpause() tüm token faaliyetini durdurur. Gerçek bir güvenlik duraklatması teoride iyidir, ancak yanlış ellerde tüm piyasa üzerinde bir dondurma düğmesidir.
- setFee() / setTaxes() alış veya satış vergisini değiştirir. Kodda sabit bir üst sınır arayın. Eğer sahip yüzde 99'luk bir satış vergisi belirleyebiliyorsa, her satış etkili bir şekilde el konulmuş demektir.
Bir blok gezgininde Yazma fonksiyonu listesi nasıl okunur?
Token'ı bir blok gezgininde açın, Sözleşme sekmesine gidin ve Sözleşme Yaz (veya token bir proxy deseni kullanıyorsa Proxy Olarak Yaz) seçeneğini seçin. Bu liste, sözleşmenin sunduğu durum değiştiren eylemlerin eksiksiz menüsüdür. Her girişi adına göre okuyun ve üç soru sorun: neyi değiştiriyor, kimin çağırmasına izin veriliyor ve ayarlanabileceği değer üzerinde bir sınır var mı?
Bir fonksiyonu kimin çağırabileceğini kontrol etmek için, Sözleşme Oku sekmesine geçin ve mevcut sahip adresini görmek için owner() öğesini bulun. Eğer sıfır adresi (0x000...000) döndürüyorsa, sahiplikten feragat edilmiştir. Ardından Kod sekmesindeki fonksiyon tanımlarına bir onlyOwner değiştiricisi veya çağırıcıyı kısıtlayan bir require ifadesi için bakın. Bakiyeleri veya ücretleri değiştiren erişim kontrolü olmayan bir fonksiyon ciddi bir kırmızı bayraktır. Eğer Solidity okumak sizin gücünüz değilse, otomatik tarayıcılar bu ön elemeyi sizin için yapar ve akıllı sözleşmeleri analiz etmek için en iyi ücretsiz araçlar hakkındaki derlememiz, ayrıcalıklı fonksiyonları otomatik olarak işaretleyenleri kapsar.
Her ayrıcalık bir geliştiricinin likiditeye dokunmadan rug pull dahil neler yapmasına izin verir?
Klasik rug pull, likidite havuzunu boşaltır ve LP kilitsizse genellikle geldiğini görebilirsiniz. Gizli sahip ayrıcalıkları, likiditeye hiç dokunmayan daha sessiz bir versiyonu mümkün kılar. Çalışan bir blacklist() ile bir geliştirici herkesin satın almasına izin verir, fiyatın yükselmesini izler, ardından yatırımcıları kara listeye alır, böylece yalnızca ekip alım tarafındaki talebe satış yapabilir. Havuz dolu kalır ve grafik, satışınızın geri döndüğü ana kadar sağlıklı görünür. Sınırsız bir setFee(), herhangi bir satışın neredeyse tamamını ekip cüzdanına yönlendirerek aynı sonucu elde eder. Bir mint() arka kapısı en yavaş ve en inkar edilebilir olanıdır: sahip sessizce büyük yeni bir tahsisat basar ve yavaş yavaş satar, sözleşme hala sıradan bir likidite kontrolünden geçerken yatırımcıları seyreltir. Bunların hiçbiri LP'yi çekmeyi gerektirmediği için, genellikle yalnızca likidite kaldırmayı izleyen araçların gözünden kaçarlar, bu yüzden daha geniş rug pull kontrol listemizin yanı sıra fonksiyon düzeyinde inceleme önemlidir.
Zararsız yönetici fonksiyonlarını yatırımcıları tuzağa düşürenlerden ayırma
Her yalnızca sahibine özel fonksiyon bir tehdit değildir. Birçok meşru token, iyi nedenlerle yönetici araçlarını tutar ve amaç paranoya değil, kalibrasyondur. Üç test, rutin fonksiyonları tuzaklardan ayırır. Birincisi, tehlikeli durum zaten güvenli yönde kilitlenmiş mi? Ticaret kalıcı olarak açık olduğunda ve fonksiyon artık onu devre dışı bırakamadığında bir ticaret geçişi iyidir. İkincisi, sabit kodlanmış bir üst sınır var mı? Örneğin, yüzde 10'u asla aşamayacak bir setFee() savunulabilirken, üst sınırı olmayan bir fonksiyon savunulamaz. Üçüncüsü, sahiplikten feragat edilmiş mi veya bir zaman kilidine ya da çoklu imzaya taşınmış mı? Hiçbir tek kişinin anında tetikleyemeyeceği bir ayrıcalık, anonim bir EOA tarafından kontrol edilen bir ayrıcalıktan çok daha az tehlikelidir. Gerçekten iyi niyetli örneklere, lansmanda açılan ve kapatılamayan tek seferlik bir enableTrading(), yönlendiriciler ve sözleşmenin kendisi için bir excludeFromFee() ve likidite havuzu yerine ücret cüzdanıyla sınırlı bir çekme fonksiyonu dahildir. Bu değerlendirmeyi, sözleşme okumasının birkaç girdiden biri olması için bir token satın almadan önce güvenli olup olmadığını nasıl kontrol edeceğinize dair daha geniş rehberimizle birleştirin.
Hızlı bir sahip ayrıcalığı denetim kontrol listesi
Herhangi bir token satın almadan önce bu sırayı uygulayın. Birkaç dakika sürer ve en yaygın tuzakları yakalar:
- Sözleşmenin doğrulanmış olduğunu onaylayın, böylece kaynağı gerçekten okuyabilirsiniz.
- Yazma Sözleşmesi sekmesini açın ve durum değiştiren her fonksiyonu listeleyin.
- blacklist, pause, mint, ticaret geçişi, max-tx ve ücret ayarlayıcılarını işaretleyin.
- Her işaret için erişim kontrolünü kontrol edin: kimin çağırabileceğini ve sahiplikten feragat edilmiş mi, zaman kilitli mi yoksa çoklu imzalı mı olduğunu.
- Vergi ayarlayıcılarının sabit kodlanmış bir üst sınırı olup olmadığını ve bu üst sınırın ne olduğunu kontrol edin.
- Herhangi bir ticaret geçişinin lansmandan sonra tekrar kapatılamayacağını onaylayın.
- Kaçırdığınız herhangi bir şeyi yakalamak için otomatik bir tarayıcıyla çapraz kontrol yapın.
- Eğer tek bir anonim cüzdan satışları dondurabilir, vergileri sınırsız yükseltebilir veya arz basabilirse, token ne kadar temiz görünürse görünsün yüksek riskli olarak değerlendirin.
Sizi koruyan disiplin basittir: bir sözleşmeyi taktığı rozetlere göre değil, sahibinin yapmasına izin verilenlere göre yargılayın. Doğrulanmış ve feragat edilmiş girdilerdir, asla sonuçlar değil. Yazma sekmesini okumak bir alışkanlık haline geldiğinde, gizli kaldıraçlar gizli olmaktan çıkar.
Bu makale yalnızca eğitim amaçlıdır ve finansal tavsiye değildir.