Kripto sözleşme doğrulaması, DeFi ekosisteminde kimliğin kesin kanıtıdır, belirsiz bytecodeyi güvenilir mantığa dönüştürür. Bununla birlikte, süreç çoğunlukla yanlış anlaşıldığında, kompilatörün "Deterministic Black Box" eşleşmeyen parmak izleri ürettiği zaman hayal kırıklığına yol açar. Bu makale doğrulamayı "Görüntü Mekanizması" olarak görselleştirerek, yerel oluşturma ortamlarının dağıtım koşullarını doğru bir şekilde kopyalaması gerektiğini gösterir. CLI araçları ve "Standard JSON Giriş" - karanlık doğrulama hatalarına karşı nihai silah. Son olarak, agresif gazIR optimizasyonları ve doğrulama karmaşıklığı arasındaki kritik değişimleri analiz ediyoruz ve size dayanı Introduction Kripto sözleşme doğrulaması sadece Etherscan'da yeşil bir işaret almakla ilgili değildir; kodunuz için nihai kimlik kanıtıdır. Geliştirildikten sonra, bir sözleşme kaynağını kanıtlamak ve güvenilmez bir ortamda mülkiyet kurmak için, doğrulama zorunludur. DeFi ekosisteminde şeffaflık, güvenlik ve kompozibilite için temel bir gereksinimdir. O olmadan, bir sözleşme hexadecimal bytecode'nin belirsiz bir parçası kalır - kullanıcılar için okunamaz ve diğer geliştiriciler tarafından kullanılamaz. Ayna Mekanizması Doğrulama hatalarını yenmek için, öncelikle sağlanan kaynak kodunun zincir üzerinde dağıtılan tam olarak aynı şifre kodunu ürettiğini kanıtlamak için blok araştırmacısı (örneğin, Etherscan) yeniden oluşturmalıdır. Şekil 1'de gösterildiği gibi, bu süreç bir "Görüntü Mekanizması" olarak hareket eder. doğrulayıcı kaynak kodunuzu bağımsız olarak oluşturur ve çıkış byte-byte'i zincirdeki verilerle karşılaştırır. Bir bajt bile farklıysa, doğrulama başarısız olur.Bu bizi her Solidity geliştiricisinin temel mücadelesine götürür. Deterministik Siyah Kutusu Teorik olarak, "byte-perfect" eşleştirme kolay geliyor. Pratikte, bu kabus başlar. Bir geliştiricinin mükemmel bir şekilde çalışan bir dApp'e sahip olabileceği, yerel testlerin% 100'ünü geçmesi, ancak kendilerini doğrulama limbo'da sıkışmış bulabilir. Neden? Çünkü Solidity compiler bir Deterministic Black Box. Şekil 2'de gösterildiği gibi, çıkış bytecode yalnızca kaynak kodu tarafından belirlenmez. Bu onlarca görünmez değişkenin ürünü: compiler sürümleri, optimizasyon çalışmaları, metadata hashleri ve hatta belirli EVM sürümü. Etherscan'ın varsayımlarına göre yerel hardhat.config.ts'deki hafif bir çelişki - örneğin farklı bir viaIR ayarı veya eksik bir proxy yapılandırması - tamamen farklı bir bytecode hash'e (Bytecode B) yol açacak ve korkutucu "Bytecode Mismatch" hatasına neden olacaktır. Bu kılavuzun amacı, doğrulamanın çalıştığı bir geliştiriciden kara kutuyu kontrol eden bir mastermind'e dönüştürmektir. standart CLI akışlarını, manuel overrides'i keşfedeceğiz ve nihayet, gelişmiş optimizasyonların bu kırılgan süreci nasıl etkilediğine dair veri yönlendirilmiş fikirler sunacağız. The CLI Approach – Precision & Automation Önceki bölümde, doğrulama sürecini bir “Görüntü Mekanizması” olarak görselleştirdik (Şekil 1). Amacınız yerel birleşimin uzaktan çevreye mükemmel bir şekilde uyumlu olmasını sağlamaktır. bir web UI aracılığıyla manuel olarak bunu yapmak hata eğilimindedir; compiler sürümünü indirmek için tek bir yanlış tıklama, hash'i mahvedebilir. Bu, Command Line Interface (CLI) araçlarının parlak olduğu yerdir. hem dağıtım hem de doğrulama için tam olarak aynı yapılandırma dosyasını (hardhat.config.ts veya foundry.toml) kullanarak, CLI araçları, "Deterministic Black Box" (Şekil 2)'i etkili bir şekilde yönetilebilir bir boru hattı haline getirerek tutarlılığı sağlar. Sıkıntılı Kontrol Çoğu geliştirici için, hardhat-verify eklentisi ilk savunma çizgisidir. Bu, inşaat eserlerinin çıkarılmasını otomatikleştirir ve doğrudan Etherscan API ile iletişim kurar. Bunu etkinleştirmek için, hardhat.config.ts'inizin etherscan yapılandırmasını içerdiğinden emin olun. Bu genellikle ilk başarısızlık noktasının meydana geldiği yerdir: Network Mismatch. // hardhat.config.ts import "@nomicfoundation/hardhat-verify"; module.exports = { solidity: { version: "0.8.20", settings: { optimizer: { enabled: true, // Critical: Must match deployment! runs: 200, }, viaIR: true, // Often overlooked, causes huge bytecode diffs }, }, etherscan: { apiKey: { // Use different keys for different chains to avoid rate limits mainnet: "YOUR_ETHERSCAN_API_KEY", sepolia: "YOUR_ETHERSCAN_API_KEY", }, }, }; Komut: Bir kez yapılandırıldıktan sonra, doğrulama komutu basittir. Sözleşmeyi yerel olarak oluşturmak için yeniden yapılandırır ve daha sonra kaynak kodunu Etherscan'a gönderir. Mastermind İpucu: Her zaman doğrulamadan önce npx hardhat temiz çalıştırın. Stale eserler (daha önce farklı ayarlar ile önceki bir oluşturulardan saklanan bytecode) doğrulama girişimlerinin sessiz bir katilidir. npx hardhat verify --network sepolia <DEPLOYED_CONTRACT_ADDRESS> <CONSTRUCTOR_ARGS> Yapımcı argümanlarının çöküşü Sözleşmenizde bir yapımcı varsa, doğrulama önemli ölçüde zorlaşır. CLI, oluşturma kodu imzasının yeniden oluşturulması için dağıtımı sırasında geçirdiğiniz tam değerleri bilmelidir. Bir senaryo kullanılarak dağıtıldıysanız, "Tek Gerçek Kaynağı" tutmak için ayrı bir argument dosyası (örneğin, arguments.ts) oluşturmalısınız. // arguments.ts module.exports = [ "0x123...TokenAddress", // _token "My DAO Name", // _name 1000000n // _initialSupply (Use BigInt for uint256) ]; Neden önemli: Bir yaygın hata "1000000" (şifre) yerine "1000000" (şifre) veya "10000000n" (BigInt) geçiyor. CLI araçları bunları ABI Hex'e farklı bir şekilde kodlar. ABI kodlaması bir bit bile farklıysa, elde edilen bytecode imzası değişir ve Şekil 1'deki " karşılaştırma" adımı bir Mismatch'e neden olur. fonksiyon kontrolü Foundry araç zincirini kullananlar için, doğrulama hızla artıyor ve natively forge'a inşa edilmiştir. Hardhat'ın aksine, bir eklenti gerektiren, Foundry bu işi kutudan çıkarıyor. forge verify-contract \ --chain-id 11155111 \ --num-of-optimizations 200 \ --watch \ <CONTRACT_ADDRESS> \ src/MyContract.sol:MyContract \ <ETHERSCAN_API_KEY> The Power of --watch: Foundry's --watch bayrağı, statü için Etherscan'ı inceleyen bir "verboz modu" gibi davranır. Gönderinin kabul edildiği veya "Bytecode Mismatch" nedeniyle başarısız olup olmadığı konusunda size anında geri bildirim verir, tarayıcı penceresini yenilemekten korur. Mükemmel yapılandırma ile bile, AggregateError veya "Fail - Unable to verify" gibi belirsiz hatalar karşılaşabilirsiniz. Zincirli ithalat: Sözleşmeniz 50'den fazla dosyayı ithal eder ve Etherscan'ın API, devasa JSON payload'ı işler. Kütüphane Bağlantısı: Sözleşmeniz henüz doğrulanmamış dış kütüphaneye dayanır. Bu "Kod Kırmızı" senaryolarında, CLI sınırını atar. otomatik senaryoları terk etmeliyiz ve kaynak kodu kendisi üzerinde manuel olarak çalışmalıyız. Bu bizi nihai doğrulama tekniğine götürür: Standart JSON Girişi. Standard JSON Input Hardhat-verify, yavaş bir ağ bağlantısı nedeniyle belirsiz bir AggregateError veya zamanlar atarsa, çoğu geliştirici panik yapar. Sözleşmelerinizin düzleştirilmesini durdurun. düzleştirme proje yapısını yok eder, ithalatları kırar ve genellikle lisans tanımlayıcılarını karıştırır ve daha fazla doğrulama hatasına yol açar. Doğru, profesyonel geri dönüş, Standart JSON Girişi'dir. Solidity Compiler'ı (solc) bir makine olarak düşünün. VS Code kurulumunuz, node_modules klasörünüz veya yeniden yapılandırmalarınız umurunda değildir. Sadece bir şeyle ilgilenir: kaynak kodu ve yapılandırmayı içeren belirli bir JSON nesnesi. Standart JSON, doğrulamanın lingua franca (toplu dil)idir. Etiket Arşivi: “Solidity” Ayarlar: Optimizer çalışıyor, EVM sürümü, viaIR, Remappings. Kaynaklar: Kullanılan her dosyanın (OpenZeppelin bağımlılıkları da dahil olmak üzere) bir sözlük, içeriği şeritler olarak yerleştirilmiştir. Standart JSON'u kullandığınızda, dosya sistemini eşitlikten kaldırıyorsunuz. Etherscan'a, kompilatörün ihtiyacı olan tam hammadde payload'ını veriyorsunuz. Hardhat’tan “Altın Bilet” çıkarma Bu JSON'u manuel olarak yazmanıza gerek yok. Hardhat bunu her kompile ettiğinizde oluşturur, ancak artifakt klasöründe derinlerde saklar. CLI doğrulamanız başarısız olursa, şu "Gelecekte cam kırma" prosedürünü izleyin: Örneğin, a1b2c3...json. açın. İçeride, üst düzey giriş nesnesi arayın. Tüm giriş nesnesi kopyalayın ve verify.json olarak kaydedin. Mastermind İpucu: Bu verify.json "Gerçeğin Kaynağı"dır. Sözleşmelerinizin kelime metni ve bunları oluşturmak için kullanılan tam ayarları içerir. Eğer bu dosya bytecodeyi yerel olarak yeniden oluşturmanıza izin verirse, Etherscan'da çalışmalıdır. İnşaat bilgilerini bulamıyorsanız veya standart olmayan bir ortamda çalışıyorsanız, panik yapmanıza gerek yok.Standard JSON Girişini basit bir Typescript bölümüyle kendiniz oluşturabilirsiniz. Bu yaklaşım size Etherscan'a ne gönderildiğine dair mutlak kontrol sağlar, böylece ithalatları ve yeniden yapılandırmalarını açıkça ele alabilirsiniz. // scripts/generate-verify-json.ts import * as fs from 'fs'; import * as path from 'path'; // 1. Define the Standard JSON Interface for type safety interface StandardJsonInput { language: string; sources: { [key: string]: { content: string } }; settings: { optimizer: { enabled: boolean; runs: number; }; evmVersion: string; viaIR?: boolean; // Optional but crucial if used outputSelection: { [file: string]: { [contract: string]: string[]; }; }; }; } // 2. Define your strict configuration const config: StandardJsonInput = { language: "Solidity", sources: {}, settings: { optimizer: { enabled: true, runs: 200, }, evmVersion: "paris", // ⚠️ Critical: Must match deployment! viaIR: true, // Don't forget this if you used it! outputSelection: { "*": { "*": ["abi", "evm.bytecode", "evm.deployedBytecode", "metadata"], }, }, }, }; // 3. Load your contract and its dependencies manually // Note: You must map the import path (key) to the file content (value) exactly. const files: string[] = [ "contracts/MyToken.sol", "node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol", "node_modules/@openzeppelin/contracts/token/ERC20/IERC20.sol", // ... list all dependencies here ]; files.forEach((filePath) => { // Logic to clean up import paths (e.g., removing 'node_modules/') // Etherscan expects the key to match the 'import' statement in Solidity const importPath = filePath.includes("node_modules/") ? filePath.replace("node_modules/", "") : filePath; if (fs.existsSync(filePath)) { config.sources[importPath] = { content: fs.readFileSync(filePath, "utf8"), }; } else { console.error(`❌ File not found: ${filePath}`); process.exit(1); } }); // 4. Write the Golden Ticket const outputPath = path.resolve(__dirname, "../verify.json"); fs.writeFileSync(outputPath, JSON.stringify(config, null, 2)); console.log(`✅ Standard JSON generated at: ${outputPath}`); Neden her zaman işe yarıyor Standart JSON'u kullanmak, metadata hash'i korur çünkü düzleştirme daha iyidir. Bir dosyayı düzleştirdiğinizde, teknik olarak kaynak kodunu değiştiriyorsunuz (importajları kaldırmak, satırları yeniden düzenlemek). Bu bazen elde edilen bytecode metadata değiştirebilir, parmak izi uyuşmazlığına yol açar. Standart JSON doğrulaması başarısız olursa, sorun, kaynak kodunuzda değil, ayarlarınızda (Şekil 2) %100'dir. The viaIR Trade-off Gömülmeden önce, odadaki fille uğraşmak zorundayız: viaIR. Modern Solidity gelişiminde (özellikle v0.8.20+), viaIR etkinleştirmek minimum gaz maliyetlerini elde etmek için standart haline gelmiştir, ancak doğrulama karmaşıklığı için yüksek bir fiyatla birlikte gelir. Pipeline Değişimi Basit bir gerçek / sahte bayrak neden bu kadar karışıklık yaratır? Legacy Pipeline: Solidity'yi doğrudan Opcode'a çevirir. yapısı kodunuzu büyük ölçüde yansıtır. IR Pipeline: İlk önce Solidity'yi Yul'a çevirir (Ortalama Gösterim). optimizör daha sonra bu Yul kodu agresif bir şekilde yeniden yazar - fonksiyonları ekleme ve stack işlemlerini yeniden düzenleme - bytecode oluşturmadan önce Şekil 3'te gösterildiği gibi, Bytecode B, Bytecode A'dan yapısal olarak farklıdır. IR boru hattı ile dağıtılan bir sözleşmeyi bir geleneksel yapılandırma kullanarak doğrulayamazsınız. Gaz verimliliği vs. güvenilirlik viaIR'ı etkinleştirme kararı, Ethereum geliştirme maliyet yapısının temel bir değişimini temsil etmektedir.Bu sadece bir compiler bayrağı değildir; yürütme verimliliği ve kompilasyon istikrarı arasındaki bir kompromistir. Geçmiş pipeline'de, kompileci büyük ölçüde bir çevirmen olarak hareket etti, Solidity ifadeleri yerel, bakış açısı optimizasyonları ile opkodlara dönüştürdü. Sonuçlanan bytecode öngörülebilirdi ve kaynak kodunun sentez yapısını yakından yansıtıyordu. Bununla birlikte, bu yaklaşım bir tavana çarptı. Karmaşık DeFi protokolleri sıklıkla "Stack Too Deep" hataları karşılaştı ve fonksiyonlar arası optimizasyonları gerçekleştirme yetersizliği kullanıcıların etkili olmayan stack yönetimi için ödeme yapmadığını ifade etti. IR boru hattı, tüm sözleşmeyi Yul'da bir bütünsel matematiksel nesne olarak ele alarak bunu çözüyor. agresif bir şekilde iç çizelge fonksiyonları, bellek yuvalarını yeniden düzenleyebilir ve tüm kod tabanında aşırı yığın işlemlerini ortadan kaldırabilir. Bununla birlikte, bu optimizasyon geliştiriciler için çarpıcı bir fiyata geliyor. Kaynak kodu ve makine kodu arasındaki "uzunluk" önemli ölçüde genişliyor. Yapısal Divergence: Optimizer gaz tasarrufu için mantıksal akışı yeniden yazdığından, elde edilen bytecode kaynağa kıyasla yapısal olarak tanımlanamıyor. "Butterfly Etkisi": IR boru hattında, küresel yapılandırmanın küçük bir değişikliği (örneğin, 200'den 201'e değişen sürüşler) tüm Yul optimizasyon ağacı boyunca yayılır. Bu nedenle, viaIR'ı etkinleştirmek yükün bir transferidir. Geliştiriciye yükü (daha uzun yapılandırma zamanları, kırılgan doğrulama, sıkı yapılandırma yönetimi) kullanıcının yükünü azaltmak için gönüllü olarak arttırıyoruz (düşük gaz ücretleri). Mastermind mühendisi olarak, bu kompromi kabul edersiniz, ancak doğrulama sürecine getirdiği kırılganlığa saygı duymalısınız. Conclusion DeFi'nin Karanlık Ormanında, kod kanun, ancak doğrulanmış kod kimliktir. Biz, doğrulama sürecini bir sihirli düğme olarak değil, bir “Görüntü Mekanizması” olarak görselleştirerek başlattık (Şekil 1). “Deterministic Black Box” (Şekil 2) çözdük ve optimizasyon paradoksu ile karşı karşıya kaldık. viaIR ve agresif optimizer çalışmaları kullanılarak maksimum gaz verimliliği için çaba gösterdiğimizde, kaynak kodu ve bytecode arasındaki boşluğu genişletiyoruz. Kullanıcılarımıza daha ucuz, daha iyi bir deneyim sunmak için daha yüksek doğrulama karmaşıklığı yükünü kabul ediyoruz. Web UI'ler uygun olsa da, onlara güvenmek insan hatası getirir. profesyonel bir kripto sözleşme mühendisi olarak, doğrulama stratejiniz üç sütun üzerine inşa edilmelidir: Otomatikleştirme İlk: Dağıtım ve doğrulama yapılandırmalarınız arasında tutarlılık sağlamak için her zaman CLI araçlarıyla (hardhat-verify veya forge verify) başlayın. Doğru yapılandırma: hardhat.config.ts'inizi bir üretim varlığı olarak değerlendirin. viaIR'ı, optimizer çalıştırmayı ve Constructor Arguments'ı sürüm kontrolü altında tutun ve dağıtım eserlerine benzer hale getirin. "Standard JSON" Fallback: Otomatik eklentiler duvara çarptığında (timeouts veya AggregateError), sözleşmenizi düzleştirmeyin.Standard JSON Girişini ( "Golden Ticket") çıkarın ve cerrahi manuel yükleme yapın. Verifikasyon, dağıtımdan beş dakika sonra ele alınması gereken bir sonraki düşünce değildir. kalite mühendisliğinin son işareti, blok zincirinde çalışan kodun tam olarak yazdığınız kod olduğunu kanıtlayan.
