บอต NFT ด้วย Python เป็นโปรแกรมที่เปลี่ยนข้อสังเกตจากตลาดให้เป็นการตัดสินใจที่บันทึกไว้ และเป็นคำขอธุรกรรมเมื่อได้รับอนุญาต Python รองรับการวิจัยคอลเลกชัน ติดตามสินทรัพย์ แจ้งเตือน และกระบวนการดำเนินการได้ แต่ภาษาเองไม่ได้กำหนดว่ากระบวนการเหล่านั้นเชื่อถือได้หรือไม่ ทางเลือกออกแบบสำคัญเกี่ยวกับความหมายข้อมูล ความละเอียดจำนวน อำนาจ และการกู้คืนหลังเกิดปัญหา
รุ่นแรกที่มีประโยชน์ควรได้รับงานไม่ใหญ่ อาจเฝ้าคอลเลกชันที่รู้จัก ปรับบันทึกรายการขายเป็นมาตรฐาน ปฏิเสธราคาที่เกินเพดานคงที่ และอธิบายการตัดสินใจแต่ละครั้ง สิ่งนี้สร้างฐานที่ทดสอบได้โดยไม่ควบคุมกระเป๋า การเพิ่มการลงนามภายหลังควรเป็นการขยายการออกแบบอย่างตั้งใจ ไม่ใช่นำคีย์ส่วนตัวไปใส่ในสคริปต์ที่ส่วนอื่นยังไม่ได้ตรวจ
บทความนี้อธิบายสถาปัตยกรรมบอต NFT ด้วย Python เป็นภาษาธรรมดา ใช้จำนวนและชื่อองค์ประกอบภายในเพื่อยกตัวอย่าง โดยไม่กำหนดไลบรารีเฉพาะหรือให้ตัวซื้อขายพร้อมรัน สถาปัตยกรรมใช้ได้ตรงที่สุดกับกระบวนการ NFT บน EVM และต้องมีตัวเชื่อมเครือข่ายที่ระบุชัด เมื่อความหมายของธุรกรรมและสินทรัพย์แตกต่างกัน
กำหนดขอบเขตองค์ประกอบของบอต NFT ด้วย Python ให้ชัดเจน
แยกงานออกเป็นตัวเชื่อมสำหรับสังเกตข้อมูล แหล่งเก็บบันทึกที่ปรับเป็นมาตรฐาน ตัวประเมินนโยบาย ตัวประสานการดำเนินการ และส่วนติดต่อลงนามที่จำกัดสิทธิ์ องค์ประกอบเหล่านี้เริ่มเป็นโมดูลในโครงการเดียวกันได้ ไม่จำเป็นต้องกลายเป็นบริการแยกห้าตัว คุณค่าอยู่ที่การระบุหน้าที่ให้ชัดพอที่จะทดสอบและพิจารณาแยกกันได้
ตัวเชื่อมสังเกตข้อมูลมีหน้าที่เข้าใจรูปแบบคำตอบและข้อผิดพลาดของ API ภายนอก ไม่ควรตัดสินว่าโทเคนคุ้มค่าที่จะซื้อ ส่วนตัวประเมินนโยบายเข้าใจเกณฑ์คอลเลกชันและขีดจำกัดใช้จ่าย ไม่ควรแอบดึงราคาอื่นหากข้อสังเกตที่ได้รับไม่ผ่านกฎ ตัวประสานการดำเนินการจัดการการกระทำที่ได้รับอนุญาตและสถานะที่ยังไม่ทราบผล ขณะที่ผู้ลงนามตรวจขอบเขตอำนาจที่ร้องขออย่างแน่นอน
แต่ละขอบเขตต้องมีข้อมูลเข้าและออกที่กำหนดไว้ บันทึกรายการขายอาจมีตัวตนสินทรัพย์ ตัวตนคำสั่ง หน่วยราคา ตัวตนโทเคนชำระเงิน เวลาสังเกต และสถานะตรวจยืนยัน บันทึกการตัดสินใจเพิ่มรุ่นนโยบาย เหตุผล และยอดใช้จ่ายสูงสุดที่อนุญาต ส่วนคำขอธุรกรรมอ้างกลับไปยังการตัดสินใจนั้น จึงรักษาสายหลักฐานจากข้อมูลไปสู่การกระทำ
บันทึกเหล่านี้ทำให้มองเห็นความไม่ตรงกัน หากตัวเชื่อมรายงานราคาโทเคนในสกุลหนึ่งแต่นโยบายคาดอีกสกุล ข้อมูลนั้นควรไม่ผ่านการตรวจ การแทนด้วยสัญลักษณ์สกุลที่คุ้นโดยอัตโนมัติจะซ่อนข้อเท็จจริงที่ระบบจำเป็นต้องตรวจ ข้อผิดพลาดเล็กที่ชัดเจนดีกว่าสมมติฐานใหญ่ที่เกิดขึ้นอย่างเงียบ ๆ
จัดการตัวตนสินทรัพย์เป็นข้อมูลที่มีโครงสร้าง
ชื่อแสดงผลของ NFT มีประโยชน์ต่อคน แต่ไม่เหมาะเป็นคีย์ฐานข้อมูล สำหรับสินทรัพย์ EVM ปกติ ให้บันทึกเชน ที่อยู่สัญญา ตัวระบุโทเคน และมาตรฐาน พร้อมจำนวนเมื่อเหมาะสม ตัวระบุเดียวกันภายใต้คนละสัญญาหมายถึงคนละสินทรัพย์ และที่อยู่ที่ดูเหมือนสัญญาเดียวกันบนอีกเชนก็อยู่ในบริบทเครือข่ายต่างกัน
ตัวตนคำสั่งแยกจากตัวตนสินทรัพย์ โทเคนอาจถูกลงขายหลายครั้งตามเวลา และผู้ขายอาจแทนคำสั่งหนึ่งด้วยอีกคำสั่ง การตัดข้อมูลซ้ำโดยใช้เพียงตัวระบุโทเคนอาจทิ้งการเปลี่ยนราคาจริง หรือสับสนคำสั่งหมดอายุกับคำสั่งที่มาแทน เก็บโปรโตคอลและตัวระบุคำสั่งควบคู่กับบันทึกรายชิ้น
ใช้สตริงหรือจำนวนเต็มที่มีขนาดเหมาะสมสำหรับตัวระบุ อย่าสมมติว่าระบบปลายทางทุกตัวแทนค่าตัวระบุได้อย่างปลอดภัยด้วยเลขจุดลอยตัวทั่วไป ตัวระบุโทเคนตัวเลขขนาดใหญ่อาจผ่านการจัดการจำนวนเต็มของ Python ได้ แต่เสียความละเอียดเมื่อส่งไปให้องค์ประกอบที่ตีความเป็นค่าจุดลอยตัวฐานสอง การแปลงข้อมูลเพื่อส่งต่อเป็นส่วนหนึ่งของสถาปัตยกรรม ไม่ใช่เพียงการแสดงผล
คำแนะนำ OpenSea เรื่อง ทบทวนหน้าสินทรัพย์ ให้บริบทตัวตนที่มีประโยชน์สำหรับคนตรวจ โปรแกรมควรเก็บตัวระบุพื้นฐานที่ช่วยให้ผู้ดำเนินการแยกสินทรัพย์ของคอลเลกชันจริงออกจากรายการที่ไม่เกี่ยวข้องแต่มีภาพหรือชื่อคล้ายกัน
ใช้จำนวนเต็มโทเคนตรงขอบเขตข้อมูล
จำนวนโทเคนต้องมีทั้งตัวเลขและหน่วย ค่าดิบหนึ่งล้านมีความหมายต่างกันสำหรับโทเคนที่ใช้หกทศนิยมกับโทเคนที่ใช้สิบแปดทศนิยม เก็บจำนวนเต็มดิบ ตัวตนโทเคน และกฎทศนิยมที่ตรวจยืนยันแล้วไว้ด้วยกัน จำนวนที่ไม่มีหน่วยไม่ควรเข้าสู่การตัดสินใจใช้เงิน
สำหรับโทเคนชำระเงินสมมติที่ใช้หกทศนิยม 12.345678 หน่วยตรงกับ 12,345,678 หน่วยฐาน สินทรัพย์สามชิ้นราคาชิ้นละ 4.125000 หน่วยมีราคารวม 12.375000 หน่วย หรือ 12,375,000 หน่วยฐาน ดังนั้นขีดจำกัดนโยบาย 12.300000 หน่วยจึงขาด 75,000 หน่วยฐาน ซึ่งเท่ากับ 0.075000 หน่วย การเปรียบเทียบควรแม่นยำ แม้ส่วนติดต่อจะปัดทั้งสองตัวเลขเพื่อแสดงผลก็ตาม
จำนวนเต็ม Python เหมาะกับจำนวนหน่วยฐานที่ต้องการความแน่นอน เลขคณิตทศนิยมช่วยจัดการราคาที่คนป้อน อัตราส่วน และรายงานได้ หากแยกอ่านข้อมูลอย่างเหมาะสมและกำหนดความละเอียดกับกฎปัดเศษไว้ชัด การสร้างค่าทศนิยมจากเลขจุดลอยตัวฐานสองที่ถูกประมาณมาแล้วไม่ได้คืนค่าทศนิยมที่ตั้งใจเดิม ควรใช้สตริงตัวเลขต้นฉบับเมื่อแหล่งข้อมูลส่งมาในรูปนั้น
อย่าปัดจำนวนผู้ใช้ที่มีทศนิยมมากเกินไปให้กลายเป็นจำนวนที่ดำเนินการได้โดยไม่แจ้ง ก่อนอนุญาต ให้ตัดสินว่าจะปฏิเสธหรือใช้กฎปัดเศษที่มีเอกสารชัดเจน การปัดราคาสูงสุดขึ้นอาจทำให้เกินขีดจำกัดผู้ใช้ ส่วนการปัดจำนวนที่ต้องใช้ชำระลงอาจทำให้ธุรกรรมล้มเหลว พฤติกรรมที่ถูกต้องขึ้นอยู่กับบทบาทของจำนวนเงินนั้น
เก็บราคา ค่าธรรมเนียม และแก๊สในหน่วยของตนเอง
การซื้ออาจใช้โทเคน ERC-20 ชำระเงินและใช้ ETH ดั้งเดิมจ่ายแก๊ส ทั้งสองเป็นคนละยอดและต้องตรวจอนุญาตแยกกัน มูลค่ารายงานรวมมีประโยชน์ก็ต่อเมื่อระบุสมมติฐานการแปลงแล้ว โปรแกรมไม่ควรนำแก๊ส 0.02 ETH ไปบวกตรง ๆ กับอีกโทเคน 100 หน่วย แล้วเรียกผลว่า 100.02 หน่วย
พิจารณาธุรกรรม Ethereum ที่มีขีดจำกัดแก๊ส 150,000 และราคาแก๊สสูงสุด 40 gwei วงเผื่อแก๊สสูงสุดคือ 0.006 ETH หากธุรกรรมใช้จริง 110,000 แก๊สที่ราคามีผลจริง 25 gwei ค่าใช้จ่ายดำเนินการคือ 0.00275 ETH ตัวเลขเหล่านี้แสดงความแตกต่างระหว่างวงเผื่อที่สำรองก่อนส่งกับต้นทุนที่กระทบยอดภายหลัง
เอกสารแก๊ส Ethereum อธิบายหน่วยพื้นฐาน การพัฒนาควรคำนึงถึงประเภทธุรกรรมและเส้นทางจริงด้วย แทนที่จะสมมติว่าสูตรเดียวครอบคลุมทุกเครือข่ายหรือค่าธรรมเนียมเพิ่มเติมทุกอย่าง ใบรับและกระแสชำระเงินที่เกิดจากการดำเนินการเป็นตัวกำหนดค่าใช้จ่ายที่รับรู้ ค่าประมาณไม่ใช่บันทึกบัญชีสุดท้าย
ใช้ชื่อที่ชัด เช่น จำนวนชำระเงิน วงเผื่อเครือข่ายสูงสุด และต้นทุนเครือข่ายที่รับรู้ ช่องกำกวมชื่อ fee หรือ total ชวนให้นับซ้ำ เมื่อคำตอบ API หนึ่งรวมองค์ประกอบที่อีกรายงานบวกเข้าอีกครั้ง ตัวประสานธุรกรรมควรอธิบายได้ว่าทุกจำนวนที่สำรองมีที่มาใดและใช้หน่วยอะไร
ปรับข้อมูลภายนอกเป็นมาตรฐานโดยไม่แต่งข้อเท็จจริงที่ขาด
ตัวเชื่อม API ควรแยกช่องข้อมูลที่ไม่มีออกจากช่องที่มีค่าถูกต้องเป็นศูนย์ ราคาที่ขาดไม่ได้หมายถึงรายการขายฟรี ช่องเจ้าของที่ไม่พร้อมไม่ได้หมายถึงไม่มีใครเป็นเจ้าของโทเคน คำตอบว่างอาจหมายถึงไม่พบบันทึกที่ตรง แต่การยืนยันตัวตนล้มเหลวหรือคำขอหมดเวลารอไม่ได้ยืนยันว่าคอลเลกชันไม่มีรายการขาย
ตรวจโครงสร้างที่คาดหมายและปฏิเสธโครงสร้างที่ไม่คาดด้วยเหตุผลที่มีประโยชน์ เก็บคำตอบสาธารณะต้นฉบับให้เพียงพอ หรือเก็บตัวอ้างอิงที่ปลอดภัย เพื่อวินิจฉัยการเปลี่ยนรูปแบบข้อมูล หลีกเลี่ยงการบันทึกส่วนหัวการยืนยันตัวตนหรือค่าตั้งลับ ขณะยังเก็บตัวระบุทั่วไปและเวลาประทับไว้ การแก้ข้อผิดพลาดไม่ควรต้องเปิดเผยอำนาจที่ใช้เข้าถึงบริการ
การแบ่งหน้าต้องใช้ความระมัดระวังแบบเดียวกัน ทำตามกลไกต่อหน้าที่มีเอกสาร และเก็บความคืบหน้าเมื่อประมวลผลคอลเลกชันใหญ่ อย่าสมมติว่าหน้าแรกแทนสินทรัพย์คงเหลือปัจจุบันทั้งหมด หากบันทึกเปลี่ยนได้ระหว่างอ่านแต่ละหน้า ให้ถือผลเป็นข้อสังเกตตลอดช่วงหนึ่ง และกระทบยอดข้อมูลซ้ำหรือเปลี่ยน แทนที่จะอ้างว่าเป็นภาพสถานะทันทีโดยไม่มีหลักฐาน
ตัวห่อ API ควรรายงานสิ่งที่รู้ การหมดเวลาของช่องทางส่งคือการหมดเวลาของช่องทางส่ง ไม่ใช่การยกเลิกของผู้ขาย คำตอบรูปแบบผิดคือการแยกข้อมูลล้มเหลว ไม่ใช่สัญญาณซื้อขายเชิงลบ การใช้หมวดข้อผิดพลาดที่แม่นยำป้องกันนโยบายจากการทำตามเรื่องที่ข้อมูลไม่เคยบอกจริง
จัดการเหตุการณ์เป็นข้อสังเกต ไม่ใช่คำสั่ง
เหตุการณ์รายการขายควรกระตุ้นให้ประเมิน ไม่ใช่ซื้อทันทีเพียงเพราะข้อความมาถึง เหตุการณ์อาจซ้ำ ล่าช้า หรือถูกเหตุการณ์อื่นแทน งานประมวลผลควรทำตัวตนให้เป็นมาตรฐาน บันทึกเวลา เทียบกับสถานะที่มี และตัดสินว่าจำเป็นต้องตรวจข้อมูลใหม่หรือไม่ ก่อนขออำนาจใช้จ่ายใด ๆ
เอกสาร Stream API ของ OpenSea อธิบายการส่งแบบพยายามให้ดีที่สุดและเหตุการณ์ที่อาจมาผิดลำดับ ดังนั้นการเชื่อมต่อใหม่ต้องมีเส้นทางกระทบยอดที่ค้นพบการเปลี่ยนซึ่งพลาดระหว่างช่องว่างได้ การออกแบบกู้คืนที่แน่นอนขึ้นอยู่กับบันทึกที่กลยุทธ์ต้องใช้ แต่ไม่ควรสมมติว่าสตรีมเหตุการณ์เป็นสมุดบัญชีที่ครบถ้วนและถาวร
แยกการป้องกันข้อมูลซ้ำออกจากความใหม่ของข้อมูล สำเนาเหตุการณ์เดียวกันสองชุดไม่ควรทำให้เกิดสองการกระทำ แต่ข้อสังเกตต่างกันสองรายการเกี่ยวกับโทเคนเดียวอาจสำคัญทั้งคู่ เพราะรายการหนึ่งเปลี่ยนสถานะคำสั่ง คีย์ตัดข้อมูลซ้ำที่กว้างเกินไปอาจเสียหายพอ ๆ กับการไม่ตัดซ้ำ หากมันกดทับอัปเดตที่ถูกต้อง
การซ้อมง่าย ๆ อาจส่งข้อสังเกตเดียวกันสองครั้ง แล้วส่งข้อมูลการยกเลิกที่มีลำดับการมาถึงก่อนกว่าแต่มีเวลาประทับเหตุการณ์ที่เกี่ยวข้อง ผลที่คาดคือบันทึกรายการพิจารณาเดียวพร้อมประวัติสถานะที่ย้อนรอยได้ ไม่ใช่การซื้อสองครั้งหรือการเชื่อข้อความที่มาถึงล่าสุดโดยไม่ตรวจ กำหนดความคาดหมายเหล่านี้ก่อนเชื่อมโปรแกรมกับอำนาจใช้งานจริง
ประสานการตัดสินใจพร้อมกันด้วยขีดจำกัดร่วม
โปรแกรม Python มักใช้งานอะซิงโครนัสเพื่อจัดการคำขอเครือข่ายหลายรายการโดยไม่ต้องรอทำทีละรายการ วิธีนี้ช่วยให้ตอบสนองดีขึ้นได้ แต่สร้างคำถามเกี่ยวกับสถานะที่ใช้ร่วมกัน การประเมินตัวเลือกสองรายการอาจเห็นงบพร้อมใช้เดียวกันก่อนฝ่ายใดบันทึกการสำรอง การประมวลผลที่เร็วขึ้นไม่ได้ทำให้การแข่งขันแย่งสถานะนั้นมีผลน้อยลง
สมมติว่าแคมเปญมีโทเคนชำระเงินพร้อมใช้ 600 หน่วย และงานประมวลผลสองตัวต่างเสนอซื้อ 400 หน่วย แต่ละข้อเสนอผ่านเมื่อดูแยก แต่รวมกันต้องใช้ 800 หน่วย ตัวประสานต้องอนุญาตได้มากที่สุดหนึ่งข้อเสนอตามงบนั้น อีกงานควรเห็นยอดที่เหลือ 200 หน่วย แล้วไม่ผ่านหรือรอตามนโยบาย
ล็อกอะซิงโครนัสภายในโปรเซสประสานงานที่ร่วมมือกันในโปรเซสเดียวได้ แต่ไม่ประสานโปรเซสแยก คอมพิวเตอร์อื่น หรือการซื้อด้วยมือจากกระเป๋าเดียวกันโดยอัตโนมัติ เมื่ออำนาจกระจายกว้างกว่านั้น ต้องมีสมุดบัญชีร่วมที่คงทนและการอัปเดตเชิงธุรกรรมที่เหมาะสม ระบุให้ชัดว่ากลไกประสานที่เลือกปกป้องขอบเขตใดจริง
จำกัดจำนวนคำขอที่ค้างด้วย การทำงานพร้อมกันโดยไม่จำกัดอาจสร้างคิวตัวเลือกเก่าที่ยาวขึ้น ทำให้บริการภายนอกรับภาระเกิน และทำให้ติดตามการกู้คืนยาก เคารพขีดจำกัดที่มีเอกสาร และหน่วงเพิ่มอย่างตั้งใจหลังความล้มเหลวที่ลองซ้ำได้ เป้าหมายคือการตัดสินใจที่เป็นปัจจุบันและอธิบายได้ ไม่ใช่จำนวนคำขอพร้อมกันสูงสุด
เก็บเจตนาไว้ก่อนขอลายเซ็น
ก่อนขอลายเซ็น ให้บันทึกเจตนาอย่างคงทน โดยระบุสินทรัพย์ เส้นทาง สกุลเงิน จำนวนสูงสุด ผู้รับ รุ่นนโยบาย และเวลาหมดอายุที่เกี่ยวข้องซึ่งได้รับอนุมัติ กำหนดตัวระบุให้เจตนานั้นเพื่อใช้ตลอดกระบวนการ ผู้ลงนามควรได้รับข้อมูลที่มีโครงสร้างเพียงพอสำหรับเทียบคำขอกับบันทึกนี้ ไม่ใช่ก้อนข้อมูลไร้คำอธิบายที่มาพร้อมป้ายชวนมั่นใจ
ข้อมูลรับรอง API กับอำนาจลงนามกระเป๋าเป็นความลับต่างชนิดและให้อำนาจต่างกัน บริการข้อมูลอาจต้องใช้คีย์เพื่ออ่านบันทึกที่ได้รับอนุญาต โดยไม่มีเหตุผลต้องเข้าถึงความลับกระเป๋า การแยกอำนาจเหล่านี้ลดจำนวนองค์ประกอบที่อนุญาตธุรกรรมได้ และทำให้จำกัดผลของการเผยความลับโดยไม่ตั้งใจได้ง่ายขึ้น
ส่วนติดต่อลงนามควรปฏิเสธเชน ผู้รับ สัญญา หรือจำนวนที่ต่างจากที่อนุมัติ แม้ผู้เรียกจะบอกว่าคำขอเป็นของการซื้อที่อนุมัติแล้วก็ตาม การอนุมัติครอบคลุมการกระทำเฉพาะภายในขีดจำกัด ไม่ใช่ข้อมูลไบต์ใดก็ได้ที่งานประมวลผลสร้าง หากเส้นทางเปลี่ยนอย่างมีสาระสำคัญ ให้ขอการตัดสินใจตามนโยบายใหม่ แทนที่จะขยายความหมายการอนุมัติเดิม
ก่อนนำโค้ดมาใช้ในชั้นนี้ ให้ใช้แนวทางใน ประเมินบอต NFT จาก GitHub ชื่อคลังที่คุ้นเคยหรือการสาธิตที่ทำงานได้ไม่ได้แสดงว่าส่วนพึ่งพาส่งข้อมูลไปที่ใด หรือผู้สร้างธุรกรรมสามารถขออำนาจมากเท่าใด
ออกแบบการกู้คืนธุรกรรม NFT ด้วย Python อย่างชัดเจน
ช่วงอันตรายมักอยู่ระหว่างการส่งกับการรับทราบในเครื่อง บริการเครือข่ายอาจรับธุรกรรมแล้ว แต่ผู้เรียกหมดเวลารอก่อนเก็บผลที่ส่งกลับ การลองซ้ำทั่วไปอาจสร้างการกระทำเพิ่มเติมขณะที่ของเดิมยังค้าง การกู้คืนต้องเริ่มจากตรวจเจตนาเดิมและตัวระบุธุรกรรมก่อน
ใช้สถานะที่รักษาความไม่แน่นอน ตัวอย่างอาจเป็นเตรียมแล้ว อนุมัติแล้ว ส่งแล้ว รอดำเนินการ ยืนยันแล้ว ล้มเหลว และยังหาข้อสรุปไม่ได้ ชื่อที่ใช้จริงสำคัญน้อยกว่าข้อกำหนดหลักฐานของแต่ละสถานะ คำตอบ HTTP ที่สำเร็จไม่เหมือนการยืนยันความเป็นเจ้าของ และคำตอบที่ขาดไม่ใช่หลักฐานว่าธุรกรรมล้มเหลว
เมื่อเริ่มใหม่ ให้กระทบยอดเจตนาที่ยังไม่เสร็จก่อนประมวลผลตัวเลือกใหม่ รักษาการสำรองงบจนผลให้เหตุรองรับการเปลี่ยน หากยืนยันความเป็นเจ้าของ ให้บันทึกจำนวนสินทรัพย์และต้นทุนจริง หากยืนยันความล้มเหลว ให้คิดค่าเครือข่ายก่อนปล่อยส่วนที่เหลือ หากยังยืนยันผลไม่ได้ ให้คงสถานะไม่ทราบผลและแสดงแก่ผู้ดำเนินการ
การมินต์ต้องแยกเพิ่มเติม เพราะสินทรัพย์อาจยังไม่มีอยู่ก่อนธุรกรรม กระบวนการ มินต์ NFT อัตโนมัติ ควรเชื่อมจำนวนมินต์ที่อนุญาตเข้ากับตัวระบุที่สร้างและได้รับจริง ไม่ควรแต่งตัวระบุที่คาดหมาย เพียงเพราะสัญญามักดูเหมือนออกหมายเลขตามลำดับ
ทดสอบการตัดสินใจด้วยกรณีที่บันทึกไว้
สร้างชุดตัวอย่างสาธารณะขนาดเล็กที่ลบข้อมูลอ่อนไหวแล้ว พร้อมผลการตัดสินใจที่คาดหมาย รวมรายการขายที่ถูกต้อง สินทรัพย์ผิดเชน ราคาที่ขาด คำขอเกินงบ เหตุการณ์ซ้ำ และผลธุรกรรมที่ไม่ทราบ กรณีเหล่านี้ทดสอบพฤติกรรมที่มีความหมายตรงขอบเขตซึ่งความผิดพลาดอาจเปลี่ยนการใช้จ่ายหรือสินทรัพย์คงเหลือ
ทดสอบการแปลงจำนวนเต็มด้วยค่าที่ต่ำกว่าขีดจำกัดเล็กน้อย เท่าขีดจำกัดพอดี และสูงกว่าเล็กน้อย รวมโทเคนที่มีกฎทศนิยมต่างกันด้วย การทดสอบที่ทำการคำนวณของโค้ดซ้ำโดยไม่มีผลคาดหมายอิสระอาจผ่าน ทั้งที่โค้ดกับการทดสอบเข้าใจหน่วยผิดเหมือนกัน ตรวจด้วยมือบางกรณีและเก็บเหตุผลไว้
สำหรับกระบวนการมินต์ ให้รวมกระเป๋าที่ไม่มีสิทธิ์และการจัดสรรที่หมดแล้วเป็นผลลบปกติ ระบบอัตโนมัติควรเคารพเงื่อนไขที่เผยแพร่ ไม่ใช่ถือการปฏิเสธเป็นความท้าทายให้หาทางเลี่ยง บทนโยบาย รายชื่อผู้มีสิทธิ์ NFT เพื่อกำไร ช่วยแยกสิทธิ์เข้าร่วมออกจากคำถามอีกเรื่องว่า การมินต์ที่ได้รับอนุญาตมีเศรษฐศาสตร์น่าสนใจหรือไม่
สุดท้ายซ้อมการขัดจังหวะโปรเซสและการกู้คืน หยุดหลังบันทึกเจตนา หลังเตรียมลายเซ็น และหลังส่ง ระบบที่เริ่มใหม่ควรอธิบายสิ่งที่ทราบในแต่ละขอบเขต และหลีกเลี่ยงการสร้างการซื้อใหม่เพื่อล้างความไม่แน่นอน การสาธิตที่เริ่มจากสถานะสะอาดเพียงอย่างเดียวไม่ได้ทดสอบสถานะที่ก่อข้อผิดพลาดการดำเนินงานจำนวนมาก
ตรวจการตั้งค่าอย่างรอบคอบเท่าข้อมูลตลาด
การตั้งค่าเป็นอีกขอบเขตของข้อมูลนำเข้า ตัวระบุเชนที่พิมพ์ผิด จำนวนทศนิยมที่ผิด หรือการขาดงบสูงสุดอาจเปลี่ยนทุกการตัดสินใจถัดไป ขณะที่โค้ดยังทำงานตามปกติ ตรวจค่าที่จำเป็นก่อนเริ่มงานประมวลผล และปฏิเสธการตั้งค่าที่อธิบายหน่วยหรือเส้นทางที่อนุญาตไม่ได้ เลือกค่าเริ่มต้นอย่างตั้งใจ โดยเฉพาะเมื่อการละค่าอาจหมายถึงการใช้เงินไม่จำกัด
เก็บคำอธิบายการตั้งค่าที่ใช้กับแต่ละการตัดสินใจแบบมีรุ่น โดยไม่คัดความลับลงบันทึก ผู้ดำเนินการที่ตรวจการซื้อจำเป็นต้องรู้ว่าเพดานที่ใช้ตอนนั้นคือ 100 หรือ 120 หน่วย ไม่ใช่เพียงค่าที่แสดงในวันนี้ การแก้ภายหลังไม่ควรเขียนคำอธิบายการกระทำก่อนหน้าใหม่
การเปลี่ยนขีดจำกัดต้องมีกฎสำหรับภาระเดิมด้วย หากลดเพดานแคมเปญต่ำกว่าความเสี่ยงปัจจุบัน ควรป้องกันภาระเพิ่มเติมและกระตุ้นให้ทบทวน แต่ย้อนการซื้อเก่าไม่ได้ การเพิ่มเพดานควรต้องใช้อำนาจชัดเจนแบบเดียวกับการมอบหมายแรก การโหลดค่าตั้งใหม่เป็นกลไกส่งการตัดสินใจที่สะดวก ไม่ใช่สิทธิ์อิสระที่จะเปลี่ยนกลยุทธ์ ทดสอบการเปลี่ยนผ่านเหล่านี้ควบคู่กับการตรวจเริ่มต้นทั่วไป
ทำให้บอต NFT ด้วย Python ดูแลรักษาได้
API ภายนอก ส่วนพึ่งพา และเส้นทางตลาดเปลี่ยนแปลงได้ บันทึกว่าซอฟต์แวร์รุ่นที่ปล่อยทดสอบกับรุ่นและสมมติฐานรูปแบบคำตอบใด ทบทวนอัปเดตในสภาพแวดล้อมควบคุม ก่อนให้อำนาจเท่ากับรุ่นที่เคยทบทวนแล้ว การติดตั้งสำเร็จบอกได้น้อยว่าส่วนพึ่งพาที่เปลี่ยนยังรักษาพฤติกรรมที่ตั้งใจหรือไม่
เขียนรายงานให้คนที่ไม่ได้เขียนโค้ดเข้าใจ แต่ละการกระทำควรแสดงเหตุผล จำนวนที่อนุญาต ผลที่สังเกต และคำถามที่ยังไม่คลี่คลาย การวิเคราะห์ผลงานควรรวมความพยายามล้มเหลวและสินทรัพย์ที่ยังขายไม่ได้ ส่วนรายงานวิศวกรรมควรเผยปัญหารูปแบบข้อมูล ช่องว่างกู้คืน และคำขอที่ถูกปฏิเสธ ทั้งสองเป็นมุมมองของระบบที่เกี่ยวข้องกันแต่แตกต่างกัน
สถาปัตยกรรมที่มีประโยชน์ที่สุดทำให้ความผิดพลาดมีขนาดเล็กและวินิจฉัยได้ หน่วยที่แม่นยำป้องกันการใช้เงินกำกวม ขอบเขตชัดเจนจำกัดอำนาจ และบันทึกคงทนรองรับการกู้คืน Python มีเครื่องมือที่มีประโยชน์สำหรับนำแนวคิดเหล่านี้ไปใช้ แต่คุณภาพบอตมาจากความชัดเจนของการตัดสินใจที่ขอให้เครื่องมือบังคับ