กำไร:
- ความสามารถในการใช้ปัญญาประดิษฐ์เพื่อสร้างเฟรมเวิร์ก ทดสอบ และตรวจสอบแบบร่างตามไลบรารีที่ได้รับการพิสูจน์แล้ว (เช่น OpenZeppelin) และเข้าใจว่ามนุษย์รับประกันความปลอดภัยในการผลิต
- ความสามารถในการตรวจสอบเวอร์ชันของโค้ด รูปแบบ และการควบคุมการเข้าถึงที่ผลิตโดยปัญญาประดิษฐ์ผ่านการรวบรวม การทดสอบ และการทดสอบเครือข่าย
- ความสามารถในการแยกแยะว่าการคอมไพล์ไม่ได้หมายความว่ามีความปลอดภัย และเทสเน็ตและการตรวจสอบถือเป็นสิ่งสำคัญ
การเขียนสัญญาอัจฉริยะแตกต่างจากซอฟต์แวร์ทั่วไป: รหัสที่คุณเขียนเป็นแบบสาธารณะ ไม่เปลี่ยนรูป และเป็นโปรแกรมที่เคลื่อนย้ายเงินโดยตรง ในหน่วยนี้ คุณจะได้เรียนรู้วิธีใช้ AI เป็นตัวช่วยในการพัฒนาสัญญาอัจฉริยะ เราจะเรียนรู้จากการผลิตแบบร่างไปจนถึงการเขียนทดสอบ จากการเรียกคืนรูปแบบไปจนถึงการปรับค่าก๊าซ (ค่าธรรมเนียมการทำธุรกรรม) ให้เหมาะสม แต่ขอให้ชัดเจนตั้งแต่เริ่มต้น: AI สร้างพิมพ์เขียว มนุษย์รับรองว่ารหัสที่ปลอดภัยจะเข้าสู่การใช้งานจริง
พื้นฐานมาก่อน: ภาษาและสิ่งแวดล้อม
ภาษาสัญญาอัจฉริยะที่พบบ่อยที่สุดคือ Solidity (ภาษาของ Ethereum และ EVM — Ethereum Virtual Machine ซึ่งเป็นเครื่องเสมือนที่สัญญาทำงาน — เครือข่ายที่เข้ากันได้) อีกทางเลือกหนึ่งคือ Vyper (ภาษาคล้าย Python ที่มีเป้าหมายเพื่อให้มีข้อจำกัดและอ่านง่ายขึ้น) รหัสของคุณใช้แก๊ส (ต้นทุนของธุรกรรมแต่ละรายการใน blockchain) รหัสที่ไม่มีประสิทธิภาพมีราคาแพง การรักษาคำศัพท์เหล่านี้ให้ชัดเจนในบริบทที่คุณให้กับ AI ถือเป็นกุญแจสำคัญในการได้รับผลลัพธ์ที่แม่นยำ
สิ่งที่ AI มีคุณค่ามากที่สุดไม่ใช่อยู่ที่ "การเขียนตั้งแต่เริ่มต้น" แต่อยู่ที่การสร้างเฟรมเวิร์ก + รูปแบบที่ดี: การเริ่มต้นที่เป็นไปตามมาตรฐาน พิมพ์เขียวที่จะเพิ่มความเชี่ยวชาญของคุณ
เลเยอร์ของการใช้ AI ในการเขียนโค้ด
1. การสร้างโครงกระดูก AI จะขุดโครงกระดูกของโทเค็นมาตรฐาน (ERC-20) หรือ NFT (ERC-721 ซึ่งเป็นมาตรฐานสินทรัพย์ดิจิทัลที่ไม่เหมือนใคร) อย่างรวดเร็ว แต่อย่าลืมทำให้ AI ใช้ไลบรารี่ที่ได้รับการพิสูจน์แล้ว เช่น OpenZeppelin (ไลบรารีการทำสัญญามาตรฐานที่ได้รับการตรวจสอบและเชื่อถือได้ของชุมชน) กฎคือการใช้บล็อกที่ทดสอบแทนที่จะเขียนความปลอดภัยตั้งแต่เริ่มต้น
2. คำอธิบายและทบทวนฟังก์ชัน การอธิบายฟังก์ชันที่มีอยู่ให้ AI ช่วยให้คุณมองเห็นข้อผิดพลาดทางตรรกะได้ตั้งแต่เนิ่นๆ
3. การสร้างการทดสอบ AI เก่งในการสร้างกรณีทดสอบสำหรับกรณี Edge: อินพุตเป็นศูนย์, จำนวนมาก, ผู้โทรที่ไม่ได้รับอนุญาต, การโทรซ้ำ สิ่งนี้จะเตือนถึงสถานการณ์หนึ่งที่หนึ่งมีการข้ามไป
4. แก๊สและความสามารถในการอ่าน AI ระบุรูปแบบที่มีราคาแพง เช่น การเขียนพื้นที่จัดเก็บข้อมูลที่ไม่จำเป็น และแนะนำทางเลือกอื่น
คำแนะนำ: สั่งให้ AI "สร้างตามสัญญาที่ได้รับการตรวจสอบของ OpenZeppelin และเขียนการรักษาความปลอดภัยใหม่ตั้งแต่ต้น" การเขียนรหัสความปลอดภัยต้นฉบับของ AI มีความเสี่ยงมากกว่าการใช้ไลบรารี่ที่ทดสอบแล้ว
พรอมต์อ่อน / พรอมต์แรง
พรอมต์ที่อ่อนแอ:
เขียนสัญญาโทเค็นให้ฉัน
พรอมต์นี้เป็นอันตราย: ไม่ชัดเจนว่ามาตรฐานใด เชนใด ไลบรารีใด ข้อกำหนดด้านความปลอดภัยใด AI สร้างโค้ดแบบสุ่ม อาจล้าสมัย หรือไม่ปลอดภัย
พรอมต์อันทรงพลัง:
บทบาทของคุณ: นักพัฒนา Solidity อาวุโส สร้างแบบร่างโทเค็น ERC-20 สำหรับเชนที่เข้ากันได้กับ EVM กฎ:- อิงตาม ERC20 และสัญญาที่เป็นเจ้าของได้ของ OpenZeppelin ที่ตรวจสอบแล้ว- เขียนบรรทัด Solidity version และ License (SPDX) อย่างชัดเจน- มีเพียงเจ้าของเท่านั้นที่ได้รับอนุญาตให้สร้าง เพิ่มฝาปิดป้องกันการกดแบบไม่มีที่สิ้นสุด - เพิ่มความคิดเห็น NatSpec ให้กับแต่ละฟังก์ชัน - เขียนความปลอดภัยตั้งแต่เริ่มต้น; ใช้บล็อกมาตรฐาน - เพิ่มคำเตือนในตอนท้าย: "นี่คือฉบับร่าง ต้องมีการตรวจสอบและทดสอบ" ทำเครื่องหมายบริเวณที่คุณไม่แน่ใจด้วย // TODO
ความแตกต่าง: การแจ้งเตือนที่ชัดเจนจะให้บทบาท มาตรฐาน ไลบรารี ขอบเขตความปลอดภัย เอกสารประกอบ และความคาดหวังในการตรวจสอบที่ชัดเจน
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) โครงกระดูกตามมาตรฐาน:
บทบาทของคุณ: นักพัฒนา Solidity สร้างกรอบงานสัญญา [ERC-20 / ERC-721 / stake] ตามไลบรารีที่ได้รับการตรวจสอบของ OpenZeppelin เขียนใบอนุญาต SPDX และเวอร์ชัน Pragma เพิ่มการควบคุมการเข้าถึง (ผู้ที่สามารถโทรได้) ให้กับแต่ละฟังก์ชันภายนอก พลิกโฉมการรักษาความปลอดภัย ใช้บล็อกมาตรฐาน นี่คือแบบร่าง
2) การตรวจสอบฟังก์ชั่น:
ตรวจสอบฟังก์ชันต่อไปนี้เหมือนกับ Senior Developer: มันทำอะไร มีการเปลี่ยนแปลงสถานะอะไร ใครบ้างที่สามารถเรียกมันได้? ทำเครื่องหมายข้อผิดพลาดทางตรรกะที่เป็นไปได้และความเสี่ยงด้านความปลอดภัยว่าเป็นสมมติฐาน โดยเชื่อมโยงแต่ละข้อเข้ากับบรรทัดในโค้ด อย่าพูดว่า "ปลอดภัย" ตรงๆ; เพียงระบุจุดสนใจ
3) ร่างสถานการณ์ทดสอบ:
เสนอกรณีทดสอบสำหรับสัญญานี้ (อาจเป็นแบบร่างสำหรับ Foundry/Hardhat) ครอบคลุมกรณีจำกัดเป็นพิเศษ: การป้อนข้อมูลเป็นศูนย์, จำนวนมากมาก, การโทรโดยไม่ได้รับอนุญาต, การโทรซ้ำ, เงินไม่เพียงพอ เขียนสิ่งที่การทดสอบแต่ละครั้งยืนยัน
4) การตรวจสอบแก๊สและความสามารถในการอ่าน:
ในสัญญานี้ ให้ทำเครื่องหมายรูปแบบที่สามารถลดต้นทุนก๊าซได้: การเขียนพื้นที่เก็บข้อมูลที่ไม่จำเป็น การเรียกจากภายนอกในลูป การคำนวณซ้ำ อธิบายความแตกต่างก่อน/หลังในแต่ละข้อเสนอแนะ แนะนำการเพิ่มประสิทธิภาพที่ทำลายความปลอดภัย ถ้าไม่ชัดเจนให้พูดว่า "ถามผู้ตรวจสอบบัญชี"
มินิเคส 3 อัน (เป็นตัวเลข)
กรณีที่ 1 — โครงกระดูกประหยัดเวลาได้ 4 ชั่วโมง ทีมหนึ่งขุดโครงกระดูกของสัญญาการให้สิทธิตามห้องสมุดที่ได้รับการตรวจสอบกับ AI ภายใน 30 นาที ใช้เวลาประมาณ ~4 ชั่วโมงด้วยตนเอง ทีมงานทุ่มเทเวลาให้กับการรักษาความปลอดภัยและการทดสอบ ประโยชน์ที่ได้รับไม่ได้มาจากการถ่ายโอนความปลอดภัย แต่มาจากการเร่งกรอบการทำงานที่น่าเบื่อ
กรณีที่ 2 — กับดักเวอร์ชันล้าสมัย AI สร้างรูปแบบที่ส่งอีเธอร์ดิบโดยการถ่ายโอน ซึ่งไม่แนะนำอีกต่อไปเนื่องจากข้อมูลการฝึกล้าสมัย นักพัฒนาสังเกตเห็นสิ่งนี้และเปลี่ยนเป็นรูปแบบตามการโทรและการป้องกันการกลับเข้าใหม่ในปัจจุบัน บทเรียน: ไลบรารี/รูปแบบของ AI ได้รับการยืนยันว่าเป็นข้อมูลล่าสุดอยู่เสมอ AI ไม่ทราบเกินวันตัดรอบการฝึกอบรม
กรณีที่ 3 — ร่างการทดสอบปรากฏข้อผิดพลาดที่ซ่อนอยู่ การทดสอบ "ผู้โทรโดยไม่ได้รับอนุญาต" ที่ AI สร้างขึ้น พบว่านักพัฒนาลืมการควบคุมการเข้าถึงในฟังก์ชันหนึ่งๆ เฉพาะเจ้าของหายไป 1 บรรทัด ติดได้ใน 5 นาทีบน testnet อาจมีการสูญเสียเงินทุนบน mainnet บทเรียน: AI ปกปิดจุดบอดของมนุษย์ในการทดสอบ
จดจำรูปแบบการรักษาความปลอดภัยด้วย AI
AI สามารถเตือนคุณถึงรูปแบบช่องโหว่ที่ทราบได้ดี เช่น รายการตรวจสอบ รูปแบบที่พบบ่อยที่สุด:
- Reentrancy: โทรออกภายนอกโดยไม่อัปเดตสถานะ วิธีแก้ไข: ลำดับการตรวจสอบผลกระทบและการโต้ตอบ การกลับเข้าใหม่
- ขาดการควบคุมการเข้าถึง: ใครๆ ก็สามารถเรียกใช้ฟังก์ชันที่สำคัญได้
- จำนวนเต็มล้น/น้อยเกินไป: Modern Solidity จับได้ส่วนใหญ่ แต่ก็ยังมีความเสี่ยงในโค้ดระดับต่ำ
- การตรวจสอบอินพุตไม่เพียงพอ: ที่อยู่เป็นศูนย์, การควบคุมปริมาณเป็นศูนย์
- การพึ่งพาของ Oracle: การไว้วางใจแบบไร้ขอบเขตในข้อมูลภายนอก (เช่น ราคา)
ข้อควรสนใจ: AI สามารถเรียกคืนรายการนี้ได้ แต่ไม่สามารถรับประกันได้ว่ารายการในรายการจะอยู่ในรหัสเฉพาะของคุณหรือไม่ รายการตรวจสอบคือจุดเริ่มต้น ไม่ใช่การแทนที่การควบคุมคอนเทนเนอร์
ทำให้บริบทถูกต้อง: เคล็ดลับในการสร้างโค้ดที่ดีจาก AI
คุณภาพของโค้ดที่ AI สร้างขึ้นนั้นขึ้นอยู่กับคุณภาพของบริบทที่คุณให้ไว้โดยตรง ใน Web3 สิ่งนี้มีความสำคัญอย่างยิ่งเนื่องจากรายละเอียดเล็กๆ น้อยๆ หนึ่งรายการ (เชนใด เวอร์ชัน Solidity ซึ่งเป็นมาตรฐานโทเค็น) จะเปลี่ยนเอาต์พุตทั้งหมด บริบทที่ดีได้แก่:
- ห่วงโซ่เป้าหมายและสภาพแวดล้อม: Ethereum mainnet หรือเลเยอร์ 2 (sidechain ที่ถูกกว่าซึ่งทำงานบน mainchain)? ค่าน้ำมันและคุณสมบัติบางอย่างแตกต่างกันไปตามเครือข่าย
- เวอร์ชันและไลบรารี: เวอร์ชัน Solidity เวอร์ชันใดของ OpenZeppelin หากไม่มีการระบุเวอร์ชัน AI อาจสร้างรูปแบบที่ล้าสมัยและเลิกใช้แล้ว
- ข้อกำหนดด้านความปลอดภัย: มีขีดจำกัด สามารถหยุดชั่วคราว สามารถเพิ่มได้หรือไม่ สิ่งเหล่านี้ควรกล่าวตั้งแต่ต้น
- ข้อจำกัด: ล้างข้อจำกัด เช่น "อย่าใช้ชุดประกอบ" "หลีกเลี่ยงการเรียกจากภายนอก" "ปรับแก๊สให้เหมาะสมแต่ยังคงความสามารถในการอ่านได้"
เทคนิคอันทรงพลังอีกอย่างหนึ่งคือการถาม AI เกี่ยวกับแผนก่อน จากนั้นจึงถามโค้ด: "ขั้นแรกให้แสดงรายการฟังก์ชันของสัญญานี้และสิ่งที่แต่ละฝ่ายจะทำ เขียนโค้ดเมื่อฉันอนุมัติ" สิ่งนี้จะจับ AI ไปในทิศทางที่ผิดตั้งแต่เนิ่นๆ และช่วยให้คุณรักษาการตัดสินใจทางสถาปัตยกรรมไว้ได้
คำแนะนำ: ถาม AI ว่า "ทำไมคุณถึงเขียนโค้ดแบบนี้" ถาม. การอธิบายเหตุผลจะช่วยเร่งการเรียนรู้ของคุณและเผยให้เห็นข้อผิดพลาดเชิงตรรกะใดๆ (เช่น สมมติฐานด้านความปลอดภัยที่ผิดพลาด) อย่าเชื่อถือผลลัพธ์ของ AI ที่ไม่สามารถปกป้องโค้ดของตัวเองได้
ข้อผิดพลาดทั่วไป
- เพิ่มความปลอดภัยใน AI ตั้งแต่เริ่มต้น ใช้ห้องสมุดที่ผ่านการทดสอบ
- ไม่ยืนยันเวอร์ชัน/รูปแบบที่ AI สร้างขึ้น ข้อมูลการฝึกอบรมอาจเก่า
- ข้ามเทสเน็ต ร่างทุกฉบับควรทำงานบนเครือข่ายทดสอบก่อนเผยแพร่
- ไม่เพิ่ม NatSpec/เอกสารประกอบ การตรวจสอบและบำรุงรักษาทำได้ยาก
- "คอมไพล์แล้วจึงปลอดภัย" ความเข้าใจผิด การรวบรวมไม่ได้หมายความว่าจะปลอดภัย
- ลืมการควบคุมการเข้าถึง มันเป็นหนึ่งในข้อผิดพลาดที่พบบ่อยที่สุดและมีราคาแพง
โดยสรุป
- ในการเขียนสัญญาอัจฉริยะ AI จะสร้างเฟรมเวิร์ก การทดสอบ และร่างการตรวจสอบ มนุษย์รับประกันความปลอดภัยในการผลิต
- สร้างความปลอดภัยตั้งแต่ต้นแต่ขึ้นอยู่กับไลบรารี่ที่ได้รับการพิสูจน์แล้ว (เช่น OpenZeppelin)
- ความทันสมัยของเวอร์ชันและรูปแบบที่ผลิตโดย YZ ได้รับการยืนยันอยู่เสมอ
- ต้นขั้วทดสอบมีประโยชน์ในการตรวจจับจุดบอดของมนุษย์ (จำกัดกรณี การควบคุมการเข้าถึง)
- การรวบรวมไม่ได้หมายความว่าปลอดภัย เทสเน็ตและการตรวจสอบเป็นสิ่งจำเป็น
งานสมัคร
สำหรับโทเค็น ERC-20 แบบธรรมดา ให้สร้างแบบร่างโดยใช้ข้อความแจ้ง "โครงกระดูกตามมาตรฐาน" ด้านบน จากนั้น: (1) ตรวจสอบว่าใช้ไลบรารี่ที่ถูกตรวจสอบหรือไม่ (2) ตรวจสอบการควบคุมการเข้าถึง (3) สร้างการทดสอบด้วยพรอมต์ "แบบร่างกรณีทดสอบ" และรันการทดสอบผู้โทรที่หลอกลวงอย่างน้อยหนึ่งครั้ง ค้นหาและจดบันทึกจุดรักษาความปลอดภัยอย่างน้อยหนึ่งจุดที่ AI พลาดไป
รายการตรวจสอบ
- [ ] ฉันได้ระบุมาตรฐานและห่วงโซ่ไว้อย่างชัดเจนในข้อความแจ้ง
- [ ] ฉันต้องการผลงานจากห้องสมุดที่ได้รับการพิสูจน์แล้ว
- [ ] มีใบอนุญาต SPDX และเวอร์ชัน Pragma
- [ ] มีการควบคุมการเข้าถึงในทุกฟังก์ชันที่สำคัญ
- [ ] ฉันสร้างและรันการทดสอบสำหรับกรณีจำกัด
- [ ] ฉันยืนยันว่าไลบรารี/รูปแบบเป็นข้อมูลล่าสุด
- [ ] ฉันทำเครื่องหมายรหัสสำหรับการตรวจสอบและการทดสอบ ฉันไม่ได้รับการดูแลบน mainnet