Kazanimlar:
- Yapay zekayı denenmiş kütüphanelere (ör. OpenZeppelin) dayalı iskelet, test ve gözden geçirme taslağı üretmede kullanıp üretim güvenliğini insanın garanti ettiğini kavrayabilme
- Yapay zekanın ürettiği kod sürümü, kalıp ve erişim kontrolünü derleme, test ve testnet ile doğrulayabilme
- Derlenmenin güvenli olmak anlamına gelmediğini, testnet ve denetimin şart olduğunu ayırt edebilme
Akıllı sözleşme yazmak, sıradan yazılımdan farklıdır: yazdığınız kod herkese açık, değiştirilemez ve doğrudan para taşıyan bir programdır. Bu ünitede YZ'yi bir akıllı sözleşme geliştirme asistanı olarak nasıl kullanacağınızı; taslak üretimden test yazımına, kalıp hatırlatmadan gas (işlem ücreti) optimizasyonuna kadar öğreneceğiz. Ama en baştan net olalım: YZ taslak üretir; üretime giren güvenli kodu insan garanti eder.
Önce zemin: dil ve ortam
En yaygın akıllı sözleşme dili Solidity'dir (Ethereum ve EVM — Ethereum Virtual Machine, sözleşmelerin çalıştığı sanal makine — uyumlu zincirlerin dili). Alternatifi Vyper'dır (daha kısıtlı ve okunabilir olmayı hedefleyen Python'a benzer dil). Kodunuz gas (her işlemin blokzincire maliyeti) tüketir; verimsiz kod pahalıdır. Bu terimleri YZ'ye verdiğiniz bağlamda net tutmak, doğru çıktı almanın anahtarıdır.
YZ'nin en değerli olduğu yer, "sıfırdan yaz" değil, iskelet + iyi kalıp üretmektir: standartlara uygun bir başlangıç, üzerine sizin uzmanlığınızın ekleneceği bir taslak.
YZ'yi kod yazımında kullanmanın katmanları
1. İskelet üretme. Standart bir token (ERC-20) veya NFT (ERC-721 — benzersiz, tek olan dijital varlık standardı) iskeletini YZ hızla çıkarır. Ama YZ'ye mutlaka denenmiş kütüphane kullandırın: örneğin OpenZeppelin (topluluğun güvenilir, denetlenmiş standart sözleşme kütüphanesi). Sıfırdan güvenlik yazmaktansa denenmiş bloğu kullanmak kuraldır.
2. Fonksiyon açıklama ve gözden geçirme. Var olan bir fonksiyonu YZ'ye açıklatmak, mantık hatalarını erken görmenizi sağlar.
3. Test üretme. YZ, sınır durumları (edge case) için test taslağı üretmede iyidir: sıfır girdi, çok büyük sayı, yetkisiz çağıran, tekrarlı çağrı. Bu, insanın atladığı senaryoları hatırlatır.
4. Gas ve okunabilirlik. YZ, gereksiz depolama (storage) yazımı gibi pahalı kalıpları işaretleyip alternatif önerir.
İpucu: YZ'ye "OpenZeppelin'in denetlenmiş sözleşmelerini temel al, güvenliği sıfırdan yeniden yazma" talimatını verin. YZ'nin özgün güvenlik kodu yazması, denenmiş kütüphaneyi kullanmasından çok daha risklidir.
Zayıf prompt / Güclü prompt
Zayıf prompt:
Bana bir token sözleşmesi yaz.
Bu prompt tehlikelidir: hangi standart, hangi zincir, hangi kütüphane, hangi güvenlik gereksinimi belli değil. YZ rastgele, muhtemelen güncel olmayan veya güvensiz bir kod üretir.
Güçlü prompt:
Rolün: kıdemli Solidity geliştiricisi. EVM uyumlu bir zincir içinbir ERC-20 token taslağı üret. Kurallar:- OpenZeppelin'in denetlenmiş ERC20 ve Ownable sözleşmelerini temel al.- Solidity sürümünü ve lisans (SPDX) satırını açıkça yaz.- Basma (mint) yetkisi yalnızca sahipte olsun; sonsuz basmaya karşı bir üst sınır (cap) ekle.- Her fonksiyona NatSpec yorumu ekle.- Güvenliği sıfırdan yazma; standart bloğu kullan.- Sonda: "Bu taslaktır; denetim ve test şarttır" uyarısı ekle.Emin olmadığın yerleri // TODO ile işaretle.
Fark: güçlü prompt rol, standart, kütüphane, güvenlik sınırı, dokümantasyon ve doğrulama beklentisini net verir.
Dört kopyalanabilir şablon
1) Standart temelli iskelet:
Rolün: Solidity geliştiricisi. [ERC-20 / ERC-721 / staking]sözleşmesinin iskeletini OpenZeppelin denetlenmiş kütüphanesinedayanarak üret. SPDX lisansı ve pragma sürümünü yaz. Her dışfonksiyona erişim kontrolü (kim çağırabilir) ekle. Güvenliğiyeniden icat etme; standart blokları kullan. Bu bir taslaktır.
2) Fonksiyon gözden geçirme:
Aşağıdaki fonksiyonu bir kıdemli geliştirici gibi incele:ne yapıyor, hangi durumları değiştiriyor, kim çağırabiliyor?Olası mantık hatalarını ve güvenlik risklerini HİPOTEZ olarakişaretle, her birini koddaki satıra bağla. Kesin "güvenli"deme; yalnızca dikkat noktalarını sırala.
3) Test senaryosu taslağı:
Bu sözleşme için test senaryoları öner (Foundry/Hardhat içintaslak olabilir). Özellikle sınır durumlarını kapsa: sıfırgirdi, çok büyük sayı, yetkisiz çağıran, tekrarlı (reentrant)çağrı, bakiye yetersizliği. Her testin NE doğruladığını yaz.
4) Gas ve okunabilirlik incelemesi:
Bu sözleşmede gas maliyetini düşürebilecek kalıpları işaretle:gereksiz storage yazımı, döngüde harici çağrı, tekrar edenhesaplama. Her öneride önce/sonra farkını açıkla. Güvenliğibozan optimizasyon önerme; net değilse "denetçiye sor" de.
Üç mini vaka (sayılarla)
Vaka 1 — İskelet 4 saat kazandırdı. Bir ekip, denetlenmiş kütüphane temelli bir vesting (token'ların zamanla serbest bırakılması) sözleşmesinin iskeletini YZ ile 30 dakikada çıkardı; el ile ~4 saat sürüyordu. Ekip zamanı, güvenlik ve testlere ayırdı. Kazanç, güvenliği devretmekten değil, sıkıcı iskeleti hızlandırmaktan geldi.
Vaka 2 — Eski sürüm tuzağı. YZ, eğitim verisi eski olduğu için transfer ile ham Ether gönderen, artık önerilmeyen bir kalıp üretti. Geliştirici bunu fark edip güncel call tabanlı ve reentrancy korumalı kalıba çevirdi. Ders: YZ'nin kütüphane/kalıp güncelliği daima teyit edilir; YZ eğitim kesim tarihinden sonrasını bilmez.
Vaka 3 — Test taslağı gizli hatayı açtı. YZ'nin ürettiği "yetkisiz çağıran" testi, geliştiricinin bir fonksiyonda erişim kontrolünü unuttuğunu ortaya çıkardı. 1 satırlık eksik onlyOwner, testnet'te 5 dakikada yakalandı; mainnet'te fon kaybı olabilirdi. Ders: YZ testte insan kör noktasını kapatır.
Güvenlik kalıplarını YZ ile hatırlamak
YZ, bilinen zafiyet kalıplarını bir kontrol listesi gibi hatırlatmada iyidir. En sık kalıplar:
- Reentrancy: Durum güncellenmeden harici çağrı yapmak. Çözüm: checks-effects-interactions sırası, reentrancy guard.
- Erişim kontrolü eksikliği: Kritik fonksiyonu herkesin çağırabilmesi.
- Tamsayı taşması/altına düşme: Modern Solidity çoğunu yakalar ama düşük seviye kodda hâlâ risk.
- Yetersiz girdi doğrulama: Sıfır adres, sıfır miktar kontrolü yokluğu.
- Oracle bağımlılığı: Dış veriye (fiyat gibi) körü körüne güvenmek.
Dikkat: YZ bu listeyi hatırlatabilir ama listedeki bir maddenin sizin özel kodunuzda olup olmadığını garantileyemez. Kontrol listesi bir başlangıçtır; kapsayıcı denetimin yerine geçmez.
Bağlamı doğru vermek: YZ'den iyi kod almanın sırrı
YZ'nin ürettiği kodun kalitesi, doğrudan verdiğiniz bağlamın kalitesine bağlıdır. Web3'te bu özellikle kritiktir çünkü küçük bir ayrıntı (hangi zincir, hangi Solidity sürümü, hangi token standardı) tüm çıktıyı değiştirir. İyi bir bağlam şunları içerir:
- Hedef zincir ve ortam: Ethereum mainnet mi, bir Layer 2 (ana zincirin üstünde çalışan, daha ucuz yan zincir) mi? Gas maliyeti ve bazı özellikler zincire göre değişir.
- Sürüm ve kütüphane: Hangi Solidity sürümü, hangi OpenZeppelin sürümü? Sürüm belirtilmezse YZ eski, önerilmeyen kalıplar üretebilir.
- Güvenlik gereksinimleri: Üst sınır (cap) var mı, duraklatılabilir mi, yükseltilebilir mi? Bunlar en baştan söylenmeli.
- Kısıtlar: "Assembly kullanma", "harici çağrıdan kaçın", "gas'i optimize et ama okunabilirliği koru" gibi net sınırlar.
Bir başka güçlü teknik, YZ'den önce planı, sonra kodu istemektir: "Önce bu sözleşmenin fonksiyonlarını ve her birinin ne yapacağını listele; ben onaylayınca kodu yaz." Bu, YZ'nin yanlış bir yöne gitmesini erken yakalar ve sizin mimari kararı elde tutmanızı sağlar.
İpucu: YZ'ye "bu kodu neden böyle yazdın?" diye sorun. Gerekçesini açıklaması, hem sizin öğrenmenizi hızlandırır hem de mantık hatalarını (örneğin yanlış bir güvenlik varsayımını) yüzeye çıkarır. Kendi kodunu savunamayan bir YZ çıktısına güvenmeyin.
Sık yapılan hatalar
- Güvenliği YZ'ye sıfırdan yazdırmak. Denenmiş kütüphane kullandırın.
- YZ'nin ürettiği sürüm/kalıbı teyit etmemek. Eğitim verisi eski olabilir.
- Testnet'i atlamak. Her taslak canlıdan önce deneme ağında çalışmalı.
- NatSpec/dokümantasyon eklememek. Denetim ve bakım zorlaşır.
- "Derlendi, demek ki güvenli" yanılgısı. Derlenmek güvenli olmak değildir.
- Erişim kontrolünü unutmak. En sık ve en pahalı hatalardandır.
Özetle
- YZ akıllı sözleşme yazımında iskelet, test ve gözden geçirme taslağı üretir; üretim güvenliğini insan garanti eder.
- Güvenliği sıfırdan değil, denenmiş kütüphanelere (ör. OpenZeppelin) dayanarak yazdırın.
- YZ'nin ürettiği sürüm ve kalıpların güncelliği daima teyit edilir.
- Test taslakları insanın kör noktalarını (sınır durumlar, erişim kontrolü) yakalamada değerlidir.
- Derlenmek güvenli olmak değildir; testnet ve denetim şarttır.
Uygulama görevi
Basit bir ERC-20 token için yukarıdaki "standart temelli iskelet" promptunu kullanarak bir taslak üretin. Sonra: (1) denetlenmiş kütüphane kullanıp kullanmadığını kontrol edin, (2) erişim kontrollerini işaretleyin, (3) "test senaryosu taslağı" promptuyla testler üretip en az bir yetkisiz-çağıran testini gerçekten çalıştırın. YZ'nin atladığı en az bir güvenlik noktasını bulup not edin.
Kontrol listesi
- [ ] Standart ve zinciri prompt'ta net belirttim.
- [ ] Denenmiş kütüphane temelli üretim istedim.
- [ ] SPDX lisansı ve pragma sürümü var.
- [ ] Her kritik fonksiyonda erişim kontrolü var.
- [ ] Sınır durumları için test ürettim ve çalıştırdım.
- [ ] Kütüphane/kalıp güncelliğini teyit ettim.
- [ ] Kodu denetim ve test için işaretledim; mainnet'e denetimsiz almadım.