สมาร์ทคอนแทรค กําลังทําให้สามารถสร้างแอปพลิเคชันแบบกระจายอํานาจ เชื่อถือได้ และมีประสิทธิภาพ ซึ่งแนะนํากรณีการใช้งานใหม่และปลดล็อกคุณค่าสําหรับผู้ใช้ เนื่องจากสัญญาอัจฉริยะจัดการมูลค่าจํานวนมากความปลอดภัยจึงเป็นข้อพิจารณาที่สําคัญสําหรับนักพัฒนา

การยืนยันทางกฎหมายเป็นหนึ่งในเทคนิคที่แนะนำสำหรับการปรับปรุงความปลอดภัยของสัญญาฉลากการตรวจสอบแบบเชิงประจักษ์ที่ใช้วิธีการทางการ

(เปิดในแท็บใหม่)

สำหรับการระบุ การออกแบบ และการตรวจสอบโปรแกรม ได้ถูกใช้มาหลายปีเพื่อให้แน่ใจว่าความถูกต้องของระบบฮาร์ดแวร์และซอฟต์แวร์ที่สำคัญ

เมื่อนำไปใช้ในสมาร์ทคอนแทรค การตรวจสอบแบบเชิงรูปแบบสามารถพิสูจน์ว่าตรรกะธุรกิจของสัญญาตรงกับข้อกำหนดที่กำหนดไว้ เมื่อเปรียบเทียบกับวิธีอื่น ๆ ในการประเมินความถูกต้องของรหัสสัญญา เช่นการทดสอบ การตรวจสอบแบบเชิงรูปแบบจะให้ความมั่นใจที่แข็งแกร่งกว่าว่าสัญญาสมาร์ทถูกต้องทางฟังก์ชัน

FORMAL VERIFICATION คืออะไร?

การยืนยันทางกฎหมายหมายถึงกระบวนการในการประเมินความถูกต้องของระบบตามมาตรฐานทางกฎหมาย กล่าวคือ การยืนยันทางกฎหมายช่วยให้เราสามารถตรวจสอบว่าพฤติกรรมของระบบทำให้ความต้องการบางอย่างพอใจ (คือ มันทำสิ่งที่เราร้องขอ)

ลักษณะการทํางานที่คาดหวังของระบบ (สัญญาอัจฉริยะในกรณีนี้) ถูกอธิบายโดยใช้การสร้างแบบจําลองอย่างเป็นทางการในขณะที่ภาษาข้อกําหนดช่วยให้สามารถสร้างคุณสมบัติที่เป็นทางการได้ เทคนิคการตรวจสอบอย่างเป็นทางการสามารถตรวจสอบได้ว่าการดําเนินการตามสัญญาเป็นไปตามข้อกําหนดและได้รับหลักฐานทางคณิตศาสตร์เกี่ยวกับความถูกต้องของอดีต เมื่อสัญญาเป็นไปตามข้อกําหนดจะมีการอธิบายว่า "ถูกต้องตามหน้าที่", "ถูกต้องโดยการออกแบบ" หรือ "ถูกต้องโดยการก่อสร้าง"

คือโมเดลทางการ

ในวิทยาการคอมพิวเตอร์ โมเดลเชิงพิรุธ

(เปิดในแท็บใหม่)

เป็นคำอธิบายทางคณิตศาสตร์ของกระบวนการคำนวณ โปรแกรมถูกนำมาเป็นสาระแน (สมการ) โดยโมเดลจะอธิบายว่าเอาต์พุทของฟังก์ชันถูกคำนวณอย่างไรเมื่อมีอินพุท

แบบจําลองที่เป็นทางการให้ระดับของนามธรรมที่สามารถประเมินการวิเคราะห์พฤติกรรมของโปรแกรมได้ การมีอยู่ของแบบจําลองที่เป็นทางการช่วยให้สามารถสร้างข้อกําหนดอย่างเป็นทางการซึ่งอธิบายคุณสมบัติที่ต้องการของแบบจําลองที่เป็นปัญหา

เทคนิคที่แตกต่างกันถูกใช้ในการโมเดลสัญญาอัจฉริยะสำหรับการตรวจสอบทางกฎหมายอย่างเป็นทางการ ตัวอย่างเช่น บางโมเดลถูกใช้ในการคิดเชิงตรรกะเกี่ยวกับพฤติกรรมระดับสูงของสัญญาอัจฉริยะ วิธีการโมเดลเหล่านี้ใช้มุมมองกล่องดำเพื่อสัญญาอัจฉริยะ มองว่าเป็นระบบที่ยอมรับข้อมูลและปฏิบัติการคำนวณตามข้อมูลเหล่านั้น

โมเดลระดับสูงเน้นที่ความสัมพันธ์ระหว่างสมาร์ทคอนแทรคและเอเจนต์ภายนอก เช่น บัญชีที่เป็นเจ้าของภายนอก (EOA), บัญชีสัญญา และสภาพแวดล้อมบล็อกเชน เช่น โมเดลเหล่านี้เป็นประโยชน์สำหรับการกำหนดคุณสมบัติที่ระบุว่าสัญญาควรทำงานอย่างไรตอบสนองต่อการกระทำของผู้ใช้บางราย

ในทางกลับกัน แบบจำลองทางการอื่น ๆ ให้ความสำคัญกับพฤติกรรมระดับต่ำของสมาร์ทคอนแทรกท์ ในขณะที่แบบจำลองระดับสูงสามารถช่วยในการคิดว่าสัญญาการทำงาน แต่อาจล้มเหลวในการจับรายละเอียดเกี่ยวกับการทำงานภายในของการปฏิบัติ รุ่นระดับต่ำใช้มุมมองกล่องขาวในการวิเคราะห์โปรแกรมและขึ้นอยู่กับการแสดงผลระดับต่ำของการประยุกต์สมาร์ทคอนแทรค เช่นรายการโปรแกรมและกราฟการไหลควบคุม

(เปิดในแท็บใหม่)

, เพื่อคิดเชิงอุปทานเกี่ยวกับคุณสมบัติที่เกี่ยวข้องกับการดำเนินการของสัญญา

โมเดลระดับต่ำถือว่าเหมาะสมเนื่องจากพวกเขาแทนการดำเนินการจริงของสัญญาอัจฉริยะในสภาพแวดล้อมการดำเนินการของอีเธอเรียม (กล่าวคือ EVM). เทคนิคการจำลองระดับต่ำมีประโยชน์มากโดยเฉพาะในการสร้างคุณสมบัติความปลอดภัยที่สำคัญในสมาร์ทคอนแทรคและตรวจจับช่องโหว่ที่เป็นไปได้

มีข้อกำหนดทางการคณะรัฐมนตรีอย่างเป็นทางการคืออะไร?

คุณลักษณะคือเพียงข้อกำหนดทางเทคนิคที่ระบบเฉพาะใดต้องการตรงตาม ในการเขียนโปรแกรม คุณลักษณะแทนความคิดทั่วไปเกี่ยวกับการดำเนินการของโปรแกรม (คือ โปรแกรมควรทำอะไร)

ในบริบทของสัญญาอัจฉริยะข้อกําหนดอย่างเป็นทางการหมายถึงคุณสมบัติซึ่งเป็นคําอธิบายอย่างเป็นทางการของข้อกําหนดที่สัญญาต้องปฏิบัติตาม คุณสมบัติดังกล่าวถูกอธิบายว่าเป็น "invariants" และแสดงถึงการยืนยันเชิงตรรกะเกี่ยวกับการดําเนินการของสัญญาที่ต้องเป็นจริงในทุกสถานการณ์ที่เป็นไปได้โดยไม่มีข้อยกเว้นใด ๆ

ดังนั้นเราสามารถคิดของสเปกิเฟชันเป็นการรวบรวมของคำถามที่เขียนขึ้นในภาษาที่เป็นทางการที่อธิบายการดำเนินการที่ตั้งใจของสมาร์ทคอนแทรค สเปกิเฟชันครอบคลุมคุณสมบัติของสัญญาและกำหนดว่าสัญญาควรทำงานอย่างไรในสถานการณ์ต่าง ๆ จุดประสงค์ของการตรวจสอบทางอย่างเป็นทางการคือเพื่อกำหนดว่าสมาร์ทคอนแทรคมีคุณสมบัติเหล่านี้ (อินวาร์เรียท์) และว่าคุณสมบัติเหล่านี้ไม่ถูกละเมิดขณะดำเนินการ

การกำหนดข้อกำหนดอย่างเป็นทางการเป็นสิ่งสำคัญในการพัฒนาการประมวลผลอย่างปลอดภัยของสัญญาอัจฉริยะ สัญญาที่ล้มเหลวในการนำมาใช้ในเงื่อนไขหรือมีคุณสมบัติของตนถูกละเมิดในระหว่างการดำเนินการ มีโอกาสต่อสู้กับช่องโหว่ที่สามารถทำความเสียหายต่อฟังก์ชันหรือทำให้เกิดการปลอดสารสกัดได้

ประเภทของข้อกำหนดรูปแบบสำหรับสมาร์ทคอนแทรค

การระบุเงื่อนไขทางฟอร์มัลช่วยให้สามารถใช้เหตุผลทางคณิตศาสตร์เกี่ยวกับความถูกต้องของการประมวลผลโปรแกรม ด้วยโมเดลทางฟอร์มัล การระบุเงื่อนไขทางฟอร์มัลสามารถระบุเข้าไปทั้งคุณสมบัติระดับสูงหรือพฤติกรรมระดับต่ำของการประมวลผลของสัญญา

มีการทำข้อกำหนดเชิงพิถีพิถันโดยใช้องค์ประกอบของโปรแกรมตรรกะ

(เปิดในแท็บใหม่)

, ซึ่งช่วยให้สามารถใช้เหตุผลเชิงประจักษ์เกี่ยวกับคุณสมบัติของโปรแกรม ตรรกะของโปรแกรมมีกฎเกณฑ์เชิงประจักษ์ที่แสดงออกมา (ในภาษาทางคณิตศาสตร์) พฤติกรรมที่คาดหวังของโปรแกรม ตรรกะของโปรแกรมหลากหลายรูปแบบถูกใช้ในการสร้างข้อกำหนดเชิงประจักษ์รวมถึงตรรกะการเชื่อมถึง

(เปิดในแท็บใหม่)

ตรรกะชั่วคราว

(เปิดในแท็บใหม่)

และตรรกะโฮแอร์

(เปิดในแท็บใหม่)

มโนทาสสำหรับสมาร์ทคอนแทรกต์สามารถจำแนกออกเป็นสองระดับหลักๆ คือ มาตรฐานระดับสูง หรือ มาตรฐานระดับต่ำ ไม่ว่ามาตรฐานจะอยู่ในหมวดหมู่ใด มันต้องอธิบายอย่างเหมาะสมและไม่กำกวมถึงคุณสมบัติของระบบที่กำลังวิเคราะห์

ข้อมูลเฉพาะทางระดับสูง

เหมือนที่ชื่อนั้นบอกไว้แล้ว มาตรฐานระดับสูง (เรียกอีกอย่างว่า “รายละเอียดที่เชิงโมเดล”) บรรยายพฤติกรรมระดับสูงของโปรแกรม มาตรฐานระดับสูงจะเป็นรายละเอียดโมเดลที่ใช้สำหรับสมาร์ทคอนแทรคตสถานะจำกัด

(เปิดในแท็บใหม่)

(FSM) ซึ่งสามารถเปลี่ยนสถานะระหว่างกันโดยการดำเนินการ โดยใช้ตรรกะชั่วคราวเพื่อกำหนดคุณสมบัติทางรูปแบบสำหรับโมเดล FSM

โลจิกชั่วคราว

(เปิดในแท็บใหม่)

"กฎเกณฑ์สำหรับการคิดเชิงเรื่องประพจัยที่มีการจำกัดเวลา (เช่น "ฉันหิวเสมอ" หรือ "ฉันจะหิวเร็ว ๆ นี้")" เมื่อใช้กับการยืนยันอย่างเป็นทางการ ตรรกะช่วงเวลาถูกใช้เพื่อกำหนดกฎของพฤติกรรมที่ถูกต้องของระบบที่ถูกจำลองเป็น state-machines โดยเฉพาะ ตรรกะช่วงเวลาอธิบายสถานะที่ผู้ตัดสินสัญญาฉลาดสามารถอยู่ในและวิธีการที่มันเปลี่ยนไประหว่างสถานะ"

ข้อกําหนดระดับสูงโดยทั่วไปจะจับคุณสมบัติชั่วคราวที่สําคัญสองประการสําหรับสัญญาอัจฉริยะ: ความปลอดภัยและความมีชีวิตชีวา คุณสมบัติด้านความปลอดภัยแสดงถึงแนวคิดที่ว่า "ไม่มีอะไรเลวร้ายเกิดขึ้น" และมักจะแสดงความแปรปรวน คุณสมบัติด้านความปลอดภัยอาจกําหนดข้อกําหนดทั่วไปของซอฟต์แวร์ เช่น อิสระจาก deadlock

(เปิดในแท็บใหม่)

, หรือแสดงคุณสมบัติที่เฉพาะเจาะจงของโดเมนสำหรับสัญญา (เช่น นิพจน์ในการควบคุมการเข้าถึงสำหรับฟังก์ชัน ค่าที่ยอมรับของตัวแปรสถานะ หรือเงื่อนไขสำหรับการโอนโทเคน)

เช่นเดียวกับข้อกำหนดเรื่องความปลอดภัยนี้ที่ครอบคลุมเงื่อนไขในการใช้ transfer() หรือ transferFrom() ในสัญญา ERC-20 token: “การยอดคงเหลือของผู้ส่งไม่ต่ำกว่าจำนวนโทเค็นที่ร้องขอจะถูกส่ง” คำอธิบายภาษาธรรมชนิดนี้ของความมั่นคงของสัญญาสามารถถูกแปลเป็นข้อกำหนด (ทางคณิตศาสตร์) ซึ่งจากนั้นสามารถตรวจสอบอย่างเข้มงวดเพื่อความถูกต้อง

คุณสมบัติของการมีชีวิตชีวารที่บ่งบอกว่า "สิ่งที่ดีเกิดขึ้นในที่สุด" และเกี่ยวกับความสามารถของสัญญาในการก้าวหน้าผ่านสถานะต่าง ๆ ตัวอย่างของคุณสมบัติการมีชีวิตชีวาคือ "ความเป็นเหลือ" ซึ่งหมายถึงความสามารถของสัญญาในการโอนส่วนคงเหลือของมันให้กับผู้ใช้ตามคำขอ หากคุณสมบัตินี้ถูกละเว้นผู้ใช้จะไม่สามารถถอนสินทรัพย์ที่เก็บไว้ในสัญญาได้ เหมือนกับสิ่งที่เกิดขึ้นกับเหตุการณ์กระเป๋าเงินความสมดุล

(เปิดในแท็บใหม่)

.

ข้อมูลเฉพาะทางระดับต่ำ

ข้อกำหนดระดับสูงเริ่มจากโมเดลสถานะจำกัดของสัญญาและกำหนดคุณสมบัติที่ต้องการของโมเดลนี้ ในทวิภาคม ข้อกำหนดระดับต่ำ (เรียกว่า "ข้อกำหนดที่ใช้สมบัติ") บางครั้งจะโมเดลโปรแกรม (สมาร์ทคอนแทร็ก) เป็นระบบที่ประกอบด้วยคอลเล็คชันของฟังก์ชันทางคณิตศาสตร์และอธิบายพฤติกรรมที่ถูกต้องของระบบเช่นนั้น

ในคำที่ง่ายกว่า ข้อมูลสเปคเพิ่มเติมวิเคราะห์รายการตั้งแต่เชิงเหตุการณ์และพยายามกำหนดคุณสมบัติของสัญญาอัจฉริยะผ่านทางรายการเหล่านี้ รายการตั้งแต่เชิงเหตุการณ์หมายถึงลำดับของการดำเนินการฟังก์ชันที่เปลี่ยนแปลงสถานะของสัญญาอัจฉริยะ; ดังนั้น ข้อมูลสเปคเพิ่มเติมช่วยกำหนดข้อกำหนดสำหรับการดำเนินการภายในของสัญญา

มีคุณสมบัติแบบ Hoare หรือคุณสมบัติบนเส้นทางการดำเนินงาน

คุณสมบัติรูปแบบ Hoare

Hoare Logic

(เปิดในแท็บใหม่)

ให้ชุดกฎระเบียบที่เป็นรูปแบบเพื่อให้เห็นเหตุผลเกี่ยวกับความถูกต้องของโปรแกรม รวมถึงสมาร์ตคอนแทรค คุณสมบัติรูปแบบ Hoare ถูกแทนด้วย Hoare triple {P}c{Q} ที่ c เป็นโปรแกรมและ P และ Q เป็นพจน์บนสถานะของ c (กล่าวคือโปรแกรม) ที่อธิบายอย่างเป็นทางการเป็นเงื่อนไขก่อน และเงื่อนไขหลังในลำดับ

เงื่อนไขก่อนหน้าคือประพจน์ที่อธิบายเงื่อนไขที่จำเป็นสำหรับการดำเนินการของฟังก์ชันอย่างถูกต้อง; ผู้ใช้ที่เรียกเข้าสู่สัญญาต้องทำให้ความต้องการนี้เป็นจริง เงื่อนไขหลังการดำเนินการคือประพจน์ที่อธิบายเงื่อนไขที่ฟังก์ชันกำหนดไว้หากดำเนินการอย่างถูกต้อง; ผู้ใช้สามารถคาดหวังว่าเงื่อนไขนี้จะเป็นจริงหลังจากการเรียกเข้าฟังก์ชัน เกณฑ์คงตัวในตรรกะโฮแอร์คือประพจน์ที่ถูกรักษาไว้โดยการดำเนินการของฟังก์ชัน (เช่น มันจะไม่เปลี่ยนแปลง)

โฮอร์-สไตล์ของมาตรฐานสามารถรับประกันการถูกต้องบางส่วนหรือการถูกต้องทั้งหมด การปฏิบัติของฟังก์ชันสัญญาเป็น "ถูกต้องบางส่วน" ถ้าเงื่อนไขก่อนการดำเนินการเป็นจริงก่อนที่ฟังก์ชันจะดำเนินการ และหากการดำเนินการสิ้นสุดลง ก็จะเป็นจริงที่หลังการดำเนินการ

การรับรองความถูกต้องโดยสิ้นเชิงเป็นเรื่องยาก เนื่องจากบางครั้งการดำเนินการบางรายการอาจล่าช้าก่อนสิ้นสุด หรือไม่เคยสิ้นสุดเลย ก็ยังสามารถพูดได้ว่า คำถามว่าการดำเนินการสิ้นสุดลงนั้นเป็นจุดที่ไม่สำคัญก็ได้เนื่องจากกลไกของก๊าซของ Ethereum ป้องกันลูปโปรแกรมที่ไม่มีที่สิ้นสุด (การดำเนินการสิ้นสุดโดยเรียบร้อยและสิ้นสุดเนื่องจากข้อผิดพลาด 'out-of-gas' ได้)

โดยใช้ตรรกะของ Hoare สเปคของสมาร์ทคอนแทรกจะมีเงื่อนไขก่อนการดำเนินการ ภายหลังการดำเนินการ และสถานการณ์ที่กำหนดไว้สำหรับการดำเนินการของฟังก์ชันและลูปในสัญญา ข้อเงื่อนไขก่อนการดำเนินการมักเป็นเสถียรภาพที่เป็นไปได้ของข้อมูลนำเข้าสู่ฟังก์ชัน ภายหลังการดำเนินการกำหนดการตอบสนองที่คาดหวังต่อข้อมูลเหล่านั้น (เช่น การโยนข้อยกเว้นที่เฉพาะเจาะจง) ในลักษณะนี้คุณลักษณะของรูปแบบ Hoare เป็นเอฟเฟกติฟสำหรับการรับรองความถูกต้องของการปฏิบัติตามของสัญญา

โครงสร้างการยืนยันอย่างเป็นทางการหลายโครงสร้างใช้ข้อกำหนดรูปแบบ Hoare เพื่อพิสูจน์ความถูกต้องทางความหมายของฟังก์ชัน นอกจากนี้ยังสามารถเพิ่มคุณสมบัติรูปแบบ Hoare (เป็นข้อสังเกต) โดยตรงเข้ารหัสสัญญาโดยใช้คำสั่ง require และ assert ใน Solidity

ต้องใช้ข้อความแสดงเงื่อนไขเบื้องต้นหรือไม่คงที่และมักใช้เพื่อตรวจสอบอินพุตของผู้ใช้ในขณะที่ยืนยันจับ postcondition ที่จําเป็นเพื่อความปลอดภัย ตัวอย่างเช่นการควบคุมการเข้าถึงที่เหมาะสมสําหรับฟังก์ชั่น (ตัวอย่างของคุณสมบัติด้านความปลอดภัย) สามารถทําได้โดยใช้การตรวจสอบเงื่อนไขเบื้องต้นเกี่ยวกับข้อมูลประจําตัวของบัญชีการโทร ในทํานองเดียวกันค่าที่ไม่คงที่ของตัวแปรสถานะที่อนุญาตในสัญญา (เช่นจํานวนโทเค็นทั้งหมดในการหมุนเวียน) สามารถได้รับการปกป้องจากการละเมิดโดยใช้การยืนยันเพื่อยืนยันสถานะของสัญญาหลังจากการดําเนินการฟังก์ชัน

คุณสมบัติระดับติดตาม

รายละเอียดที่มีการติดตามระบุถึงการดำเนินการที่ทำให้สัญญาเปลี่ยนแปลงระหว่างสถานะต่าง ๆ และความสัมพันธ์ระหว่างการดำเนินการเหล่านี้ ตามที่อธิบายไว้ก่อนหน้า เทรกเสือเป็นลำดับของดำเนินการที่เปลี่ยนแปลงสถานะของสัญญาอย่างเฉพาะเจาะจง

วิธีนี้พึงพอใจในแบบจำลองของสมาร์ทคอนแทรคเป็นระบบการเปลี่ยนสถานะด้วยสถานะที่กำหนดไว้ล่วงหน้า (ที่อธิบายโดยตัวแปรสถานะ) ร่วมกับชุดของการเปลี่ยนสถานะที่กำหนดไว้ล่วงหน้า (ที่อธิบายโดยฟังก์ชันสัญญา) อีกด้วยกราฟการควบคุม

(เปิดในแท็บใหม่)

(CFG) ซึ่งเป็นการแสดงผังกราฟิกของการดำเนินการของโปรแกรม มักถูกใช้เพื่ออธิบายเซมันติกของสัญญา ที่นี่ ทุกขั้นตอนถูกแทนด้วยเส้นทางบนกราฟการไหลควบคุม

โดยหลักแล้ว ข้อกำหนดระดับการติดตามถูกใช้เพื่อตรวจสอบรูปแบบการปฏิบัติภายในในสมาร์ทคอนแทรค เมื่อสร้างข้อกำหนดระดับการติดตาม เรายืนยันเส้นทางการปฏิบัติ (เช่น การเปลี่ยนสถานะ) ที่ยอมรับสำหรับสมาร์ทคอนแทรค โดยใช้เทคนิค เช่น การปฏิบัติตัวแบบ เราสามารถยืนยันอย่างเป็นทางการว่าการปฏิบัติไม่เคยเดินทางตามเส้นทางที่ไม่ได้กำหนดในตัวแบบทางการ

Let’s use an example of a DAOสัญญาที่มีบางฟังก์ชั่นที่สามารถเข้าถึงได้สาธารณะเพื่ออธิบายคุณสมบัติระดับการติดตาม ที่นี่เราสมมติว่าสัญญา DAO อนุญาตให้ผู้ใช้ทำการดำเนินการต่อไปนี้:

• เงินฝาก
• โหวตข้อเสนอหลังจากฝากเงิน
• เรียกร้องคืนเงินถ้าพวกเขาไม่ลงคะแนในข้อเสนอ

คุณสมบัติระดับติดตามตัวอย่างอาจเป็น “ผู้ใช้ที่ไม่ฝากเงินไม่สามารถลงคะแนนเห็นเสนอได้” หรือ “ผู้ใช้ที่ไม่ลงคะแนนเห็นเสนอควรสามารถเรียกร้องคืนเงินเสมอได้” ทั้งสองคุณสมบัติยืนยันลำดับการดำเนินการที่ต้องการ (ลงคะแนนเห็นเสนอไม่สามารถเกิดขึ้นก่อนฝากเงินและการเรียกร้องคืนเงินไม่สามารถเกิดขึ้นหลังจากลงคะแนนเห็นเสนอ)

เทคนิคสำหรับการตรวจสอบอย่างเป็นทางการของสมาร์ทคอนแทรค

ตรวจสอบโมเดล

การตรวจสอบโมเดลเป็นเทคนิคการยืนยันอย่างเป็นทางการที่ใช้อัลกอริทึมในการตรวจสอบโมเดลเป็นสัญญาอัจฉริยะตามข้อกำหนดของมัน ในการตรวจสอบโมเดลสัญญาอัจฉริยะเช่นนี้มักถูกแทนด้วยระบบการเปลี่ยนสถานะ ในขณะที่คุณสมบัติในสถานะสัญญาที่อนุญาตถูกกำหนดโดยใช้ตรรกะเวลา

การตรวจสอบแบบจำลองต้องการสร้างการแทนที่ทางคณิตศาสตร์ในรูปแบบนามธรรมของระบบ (เช่น สัญญา) และแสดงคุณสมบัติของระบบนี้โดยใช้สูตรที่มีรากฐานในตรรกะตรรก

(เปิดในแท็บใหม่)

. นี่ทำให้งานของอัลกอริทึมการตรวจสอบโมเดลง่ายขึ้น คือการพิสูจน์ว่าโมเดลทางคณิตศาสตร์ทำให้สูตรตรรกะที่กำหนดได้

การตรวจสอบโมเดลในการตรวจสอบแบบเชิงพิสูจน์จะใช้สำหรับการประเมินคุณสมบัติเวลาที่อธิบายพฤติกรรมของสัญญาตลอดเวลา คุณสมบัติเวลาสำหรับสัญญาอัจฉริยะรวมถึงความปลอดภัยและความมีชีวิตชีวา ซึ่งเราได้อธิบายไว้ก่อนหน้า

ตัวอย่างเช่น คุณสมบัติด้านความปลอดภัยที่เกี่ยวข้องกับการควบคุมการเข้าถึง (เช่น เฉพาะเจ้าของสัญญาเท่านั้นที่สามารถเรียกใช้ selfdestruct) สามารถเขียนในตรรกะเชิงรูปแบบ จากนั้น อัลกอริทึมตรวจสอบแบบจำลองสามารถตรวจสอบว่าสัญญาตรงตามข้อกำหนดรูปแบบนี้หรือไม่

การตรวจสอบแบบจําลองใช้การสํารวจอวกาศของรัฐซึ่งเกี่ยวข้องกับการสร้างสถานะที่เป็นไปได้ทั้งหมดของสัญญาอัจฉริยะและพยายามค้นหารัฐที่สามารถเข้าถึงได้ซึ่งส่งผลให้เกิดการละเมิดทรัพย์สิน อย่างไรก็ตามสิ่งนี้สามารถนําไปสู่จํานวนรัฐที่ไม่มีที่สิ้นสุด (เรียกว่า "ปัญหาการระเบิดของรัฐ") ดังนั้นผู้ตรวจสอบแบบจําลองจึงอาศัยเทคนิคนามธรรมเพื่อให้การวิเคราะห์สัญญาอัจฉริยะเป็นไปได้อย่างมีประสิทธิภาพ

การพิสูจน์ทฤษฎี

การพิสูจน์ทฤษฎีคือวิธีการที่ใช้เหตุผลทางคณิตศาสตร์ในการตรวจสอบความถูกต้องของโปรแกรมทั้งหมด รวมถึงสัญญาอัจฉริยะ มันเกี่ยวข้องกับการแปลงโมเดลของระบบสัญญาและข้อกำหนดของมันเป็นสูตรทางคณิตศาสตร์ (คำแสดงตรรกะ)

วัตถุประสงค์ของการพิสูจน์ทฤษฎีก็คือการยืนยันความเท่าเทียมทางตรรกะระหว่างคำกล่าวเหล่านี้ "ความเท่าเทียมทางตรรกะ" (เรียกว่า "การระบุความสัมพันธ์ทางตรรกะ") เป็นประเภทของความสัมพันธ์ระหว่างคำกล่าวสองอย่างที่คำกล่าวแรกจริงก็ตรง ก็ตรงเท่านั้นเมื่อคำกล่าวที่สองเป็นจริง

ความสัมพันธ์ที่จำเป็น (ความเท่าเทียมทางตรรกะ) ระหว่างคำกล่าวเกี่ยวกับโมเดลของสัญญาและคุณสมบัติของมันถูกสูตรเป็นคำกล่าวที่สามารถพิสูจน์ได้ (เรียกว่า ทฤษฎี) โดยใช้ระบบทางตรรกะอัตโนมัติ โปรแกรมพิสูจน์ทฤษฎีสามารถยืนยันความถูกต้องของทฤษฎีได้ กล่าวอีกนัยหนึ่ง โปรแกรมพิสูจน์ทฤษฎีสามารถพิสูจน์โดยสิ้นเชิงว่าโมเดลของสัญญาตัวอัจฉริยะตรงกับข้อกำหนดของมันอย่างแม่นยำ

ในขณะที่แบบจําลองการตรวจสอบแบบจําลองสัญญาเป็นระบบการเปลี่ยนผ่านที่มีสถานะ จํากัด การพิสูจน์ทฤษฎีบทสามารถจัดการการวิเคราะห์ระบบสถานะอนันต์ อย่างไรก็ตามนี่หมายความว่าผู้พิสูจน์ทฤษฎีบทอัตโนมัติไม่สามารถทราบได้เสมอว่าปัญหาตรรกะนั้น "ตัดสินใจได้" หรือไม่

ด้วยเหตุนี้ การช่วยเหลือของมนุษย์มักจำเป็นต้องมีเพื่อคำแสดงความถูกต้อง การใช้ความพยานของมนุษย์ในการพิสูจน์ทฤษฎีทำให้มันมีค่าใช้จ่ายมากกว่าการตรวจสอบแบบโมเดลที่เป็นอัตโนมัติ

การประมวลผลสัญลักษณ์

การปฏิบัติตัวสัญลักษณ์เป็นวิธีการวิเคราะห์สัญญาอัจฉริยะโดยการปฏิบัติฟังก์ชันโดยใช้ค่าสัญลักษณ์ (เช่น x > 5) แทนค่าที่แน่นอน (เช่น x == 5) เป็นเทคนิคการยืนยันทางกฎหมายที่ใช้ในการเหตุผลเกี่ยวกับคุณสมบัติระดับติดตามในรหัสของสัญญา

การทดสอบสัญลักษณ์แทนการทดสอบเป็นสูตรทางคณิตศาสตร์เกี่ยวกับค่านำเข้าที่เป็นสัญลักษณ์ ซึ่งเรียกว่าเงื่อนไขเส้นทางSMT solver

(เปิดในแท็บใหม่)

ใช้เพื่อตรวจสอบว่าพรีดิเคตเส้นทางเป็น "สามารถพอใจ" (กล่าวคือมีค่าที่สามารถพอใจสูตร) หากพบว่าพรีดิเคตเส้นทางที่มีช่องโหว่เป็นไปได้ ตัวแก้ปัญหา SMT จะสร้างค่าที่แน่นอนที่ทำให้การดำเนินการเดินทางไปสู่เส้นทางนั้น

สมมติว่าฟังก์ชันของสัญญาอัจฉริยะใช้เป็นอินพุตค่า uint (x) และย้อนกลับเมื่อ x มากกว่า 5 และต่ํากว่า 10 การค้นหาค่าสําหรับ x ที่ทริกเกอร์ข้อผิดพลาดโดยใช้ขั้นตอนการทดสอบปกติจะต้องเรียกใช้กรณีทดสอบหลายสิบกรณี (หรือมากกว่า) โดยไม่ต้องรับประกันว่าจะพบอินพุตที่ทําให้เกิดข้อผิดพลาด

ในทางกลับกัน เครื่องมือการประมวลผลสัญลักษณ์จะทำการประมวลผลฟังก์ชันด้วยค่าสัญลักษณ์: X > 5 ∧ X < 10 (นั่นคือ x มีค่ามากกว่า 5 และ x มีค่าน้อยกว่า 10) สิ่งที่เรียกว่า Predicate x = X > 5 ∧ X < 10 จะถูกส่งให้กับ SMT solver เพื่อทำการแก้ปัญหา หากค่าใดค่าหนึ่งทำให้สมการ x = X > 5 ∧ X < 10 เป็นจริง SMT solver จะคำนวณค่านั้น 例如 ตัวแก้ปัญหาอาจจะให้ค่า 7 เป็นค่าของ x

เนื่องจากการสัญลักษณ์ขึ้นอยู่กับการป้อนข้อมูลเข้าสู่โปรแกรม และเซ็ตของข้อมูลขนาดใหญ่ที่จะสำรวจสถานะที่เข้าถึงได้ทั้งหมด อาจเป็นไปได้ว่ามีจำนวนไม่จำกัด นั่นยังคงเป็นรูปแบบหนึ่งของการทดสอบ อย่างไรก็ตาม ตามที่แสดงในตัวอย่าง การสัญลักษณ์ขึ้นอยู่กับการป้อนข้อมูลเป็นมากกว่าการทดสอบปกติเมื่อต้องการค้นหาข้อมูลของการละเมิดสมบัติ

นอกจากนี้ การดำเนินการสัญลักษณ์สร้างค่าจำนวนน้อยกว่า false positives ในเทคนิคที่ใช้สมบัติเป็นหลักอื่น ๆ (เช่น fuzzing) ที่สร้างข้อมูลนำเข้าสู่ฟังก์ชันโดยสุ่ม หากสถานะข้อผิดพลาดถูกเรียกใช้ในการดำเนินการสัญลักษณ์ แล้วสามารถสร้างค่าที่เป็นจริงที่เรียกใช้ข้อผิดพลาดและทำให้เกิดปัญหา

การดำเนินการสัญลักษณ์ยังสามารถให้บางระดับของการพิสูจน์ทางคณิตศาสตร์เกี่ยวกับความถูกต้อง พิจารณาตัวอย่างต่อไปนี้ของฟังก์ชันสัญญาที่มีการป้องกันการเกิน:

การทำรอยสะท้อนที่ส่งผลให้เกิดการเกินค่าของจำนวนเต็มจำเป็นต้องปฏิบัติตามสูตร: z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y) การทำสูตรแบบนี้นั้นน่าจะไม่สามารถแก้ไขได้ ดังนั้นมันเป็นการพิสูจน์ทางคณิตศาสตร์ว่าฟังก์ชัน safe_add จะไม่เกินค่า

เหตุใดจึงต้องใช้การยืนยันอย่างเป็นทางการสําหรับสัญญาอัจฉริยะ

ความจำเป็นของความเชื่อถือ

การตรวจสอบแบบเป็นทางการถูกใช้เพื่อประเมินความถูกต้องของระบบที่สำคัญต่อความปลอดภัย ซึ่งการล้มเหลวของระบบเหล่านี้สามารถทำให้เกิดผลกระทบที่ทรงพลัง เช่น การเสียชีวิต บาดเจ็บ หรือการถูกทำลายทางการเงิน สมาร์ทคอนแทรคต์เป็นแอปพลิเคชันค่าสูงที่ควบคุมปริมาณมูลค่ามากๆ และข้อผิดพลาดง่ายๆ ในการออกแบบอาจนำไปสู่ความสูญเสียที่ไม่สามารถกู้คืนสำหรับผู้ใช้

(เปิดในแท็บใหม่)

การตรวจสอบแบบเป็นทางการของสัญญาก่อนการใช้งาน อย่างไรก็ตาม สามารถเพิ่มความมั่นใจได้ว่ามันจะทำงานตามที่คาดหวังเมื่อทำงานบนบล็อกเชน

ความเชื่อถือได้เป็นคุณภาพที่ต้องการอย่างมากในสัญญาอัจฉริยะใด ๆ เพราะโค้ดที่ได้รับการประดิษฐ์ในเครื่องจำลอง Ethereum Virtual Machine (EVM) มักจะไม่สามารถเปลี่ยนแปลงได้ โดยทั่วไป ด้วยการอัปเกรดหลังเปิดตัวที่ไม่สามารถเข้าถึงได้ง่าย ความจำเป็นที่จะต้องรับประกันความเชื่อถือของสัญญาทำให้การตรวจสอบแบบเชิงรูปแบบเป็นเรื่องจำเป็น การตรวจสอบแบบเชิงรูปแบบสามารถตรวจจับปัญหาที่ยากลำบาก เช่น การซึ่งต่ำกว่าและท่วงท่าน การเข้าสู่ระบบอีกครั้ง และการปรับปรุงแก๊สที่ไม่ดี ซึ่งอาจมองข้ามไประหว่างผู้ตรวจสอบและผู้ทดสอบ

พิสูจน์ความถูกต้องทางฟังก์ชัน

การทดสอบโปรแกรมเป็นวิธีที่พบได้บ่อยที่สุดในการพิสูจน์ว่าสัญญาอัจฉริยะประท้วงความต้องการบางประการ ซึ่งประกอบด้วยการประมวลผลสัญญาด้วยตัวอย่างของข้อมูลที่คาดว่าจะจัดการและวิเคราะห์พฤติกรรมของมัน หากสัญญาส่งคืนผลลัพธ์ตามที่คาดหวังสำหรับข้อมูลตัวอย่าง นั้นแปลว่านักพัฒนามีหลักฐานที่เป็นธรรมของความถูกต้องของมัน

อย่างไรก็ตาม การเข้าถึงนี้ไม่สามารถพิสูจน์การดำเนินการที่ถูกต้องสำหรับค่านำเข้าที่ไม่ได้อยู่ในส่วนของตัวอย่าง ดังนั้น การทดสอบสัญญาอาจช่วยตรวจพบข้อบกพร่อง (เช่น หากบางเส้นทางของโค้ดไม่สามารถคืนผลลัพธ์ที่ต้องการในระหว่างการดำเนินการ) แต่ก็ไม่สามารถพิสูจน์อย่างแน่นอนถึงความขาดความบกพร่อง

ในทางกลับกันการตรวจสอบอย่างเป็นทางการสามารถพิสูจน์ได้อย่างเป็นทางการว่าสัญญาอัจฉริยะเป็นไปตามข้อกําหนดสําหรับการดําเนินการที่ไม่มีที่สิ้นสุดโดยไม่ต้องทําสัญญาเลย สิ่งนี้ต้องการการสร้างข้อกําหนดอย่างเป็นทางการที่อธิบายพฤติกรรมสัญญาที่ถูกต้องอย่างแม่นยําและพัฒนาแบบจําลองที่เป็นทางการ (ทางคณิตศาสตร์) ของระบบของสัญญา จากนั้นเราสามารถทําตามขั้นตอนการพิสูจน์อย่างเป็นทางการเพื่อตรวจสอบความสอดคล้องระหว่างรูปแบบของสัญญาและข้อกําหนดของสัญญา

ด้วยการตรวจสอบแบบเป็นทางการ คำถามเกี่ยวกับการตรวจสอบว่าตรรกะธุรกิจของสัญญาตรงตามความต้องการเป็นประพจัสภาพทางคณิตศาสตร์ที่สามารถพิสูจน์หรือปฏิบัติได้ โดยการพิสูจน์ประพจัสภาพอย่างเป็นทางการเราสามารถตรวจสอบจำนวนทดสอบได้ไม่จำกัดด้วยจำนวนขั้นตอนที่จำกัดได้ ในทางนี้การตรวจสอบแบบเป็นทางการมีโอกาสที่ดีกว่าในการพิสูจน์ว่าสัญญาทำงานได้ถูกต้องตามข้อกำหนด

เป้าหมายในการตรวจสอบที่เหมาะสม

เป้าหมายการตรวจสอบระบบอธิบายระบบที่จะตรวจสอบโดยเชิงพิสูจน์ การตรวจสอบโดยชั้นเชิงพิสูจน์เหมาะที่สุดสำหรับ "ระบบฝังตัว" (ซอฟต์แวร์ขนาดเล็ก ๆ ที่เป็นส่วนหนึ่งของระบบที่ใหญ่กว่า) และเหมาะสำหรับโดเมนที่เฉพาะเจาะจงที่มีกฎข้อบังคับเพียงเล็กน้อย ซึ่งทำให้ง่ายต่อการปรับเปลี่ยนเครื่องมือสำหรับการตรวจสอบคุณสมบัติที่เฉพาะเจาะจงของโดเมน

สัญญาอัจฉริยะ—อย่างน้อยแล้ว—ประทับใจทั้งสองเงื่อนไข ตัวอย่างเช่น ขนาดเล็กของสัญญา Ethereum ทำให้สามารถทำการตรวจสอบอย่างเป็นทางการ ในทำนองเดียวกัน EVM ปฏิบัติตามกฎเรียบง่าย ทำให้การระบุและการตรวจสอบคุณสมบัติตรรกะสำหรับโปรแกรมที่ทำงานใน EVM ง่ายขึ้น

รอบการพัฒนาที่เร็วขึ้น

เทคนิคการยืนยันทางกฎหมายทางการ เช่น การตรวจสอบโมเดลและการดำเนินการตรรกะ มักจะมีประสิทธิภาพมากกว่าการวิเคราะห์ทั่วไปของโค้ดสมาร์ทคอนแทรค (ที่ทำในระหว่างการทดสอบหรือการตรวจสอบ) นั้นเป็นเพราะการยืนยันทางกฎหมายทางกายภาพจะพึงพอใจในค่าสัญลักษณ์เพื่อทดสอบการยืนยัน (“Imagine what if a user tries to withdraw n ether?”) ไม่เหมือนการทดสอบที่ใช้ค่าที่เป็นตัวแทน (“Imagine what if a user tries to withdraw 5 ether?”)

ตัวแปรอินพุตสัญลักษณ์สามารถครอบคลุมคลาสหลาย ๆ ของค่าที่แน่นอน ดังนั้นวิธีการยืนยันความถูกต้องทางพิธีกรสัญญาณมักสัญญาความครอบคลุมของโค้ดมากขึ้นในช่วงเวลาที่สั้นกว่า เมื่อใช้อย่างมีประสิทธิภาพ การยืนยันความถูกต้องทางพิธีกรสามารถเร่งกระบวนการพัฒนาสำหรับนักพัฒนาได้

การตรวจสอบแบบเป็นทางการยังช่วยในกระบวนการก่อสร้างแอพลิเคชันที่มีลักษณะกระจาย (dapps) โดยการลดข้อผิดพลาดในการออกแบบที่ทำให้เสียค่าใช้จ่ายลดลง การอัพเกรดสัญญา (หากเป็นไปได้) เพื่อแก้ไขช่องโหว่ต้องทำการเขียนโค้ดใหม่โดยละเอียดและใช้ความพยายามมากขึ้นในการพัฒนา การตรวจสอบแบบเป็นทางการสามารถตรวจจับข้อผิดพลาดหลายประการในการปฏิบัติสัญญาซึ่งอาจมองข้ามไปจากผู้ทดสอบและผู้สอบบัญชี และให้โอกาสเพียงพอในการแก้ไขปัญหาเหล่านั้นก่อนการใช้ปฏิบัติสัญญา

ข้อเสียของการตรวจสอบแบบเชิงพิกล

ค่าแรงงานฝีมือ

การตรวจสอบทางกฎหมายโดยเฉพาะอย่างเป็นทางการ, โดยเฉพาะการตรวจสอบแบบ semi-automated ที่มีมนุษย์เป็นผู้นำทางให้ prover ได้รับการตรวจสอบความถูกต้อง, ต้องใช้แรงงานมือจำนวนมาก นอกจากนี้การสร้างข้อกำหนดทางกฎหมายอย่างเป็นทางการเป็นกิจกรรมที่ซับซ้อนซึ่งต้องการทักษะระดับสูง

ปัจจัยเหล่านี้ (ความพยายามและทักษะ) ทำให้การยืนยันทางกฎหมายที่เป็นทางการเป็นเรื่องที่ต้องการและมีค่าใช้จ่ายมากกว่าวิธีปกติในการประเมินความถูกต้องในสัญญา เช่นการทดสอบและการตรวจสอบ อย่างไรก็ตาม การจ่ายค่าในการตรวจสอบแบบเต็มรูปแบบเป็นเรื่องที่น่าพึงระลึก โดยพิจารณาจากค่าในการพบข้อผิดพลาดในการปฏิบัติสัญญาฉลาด

ผลลัพธ์เชิงลบที่ไม่ถูกต้อง

การตรวจสอบเชิงประการเท่านั้นที่สามารถตรวจสอบว่าการดำเนินการของสมาร์ทคอนแทรคตรงกับข้อกำหนดเชิงประการ ดังนั้น สำคัญที่จะตรวจสอบให้แน่ใจว่าข้อกำหนดอธิบายพฤติกรรมที่คาดหวังของสมาร์ทคอนแทรคอย่างเหมาะสม

หากข้อมูลจำเป็นเขียนได้ไม่ดี การละเมิดทรัพย์สิน—ซึ่งชี้ไปที่การปฏิบัติที่อ่อนแอ—อาจไม่สามารถตรวจจับได้โดยการตรวจสอบการยืนยันอย่างเป็นทางการ ในกรณีนี้ นักพัฒนาอาจถูกคิดว่าสัญญาไม่มีข้อผิดพลาด

ปัญหาเรื่องประสิทธิภาพ

การยืนยันแบบเป็นทางการเผชิญกับปัญหาด้านประสิทธิภาพหลายอย่าง ตัวอย่างเช่น ปัญหาของการขยายสถานะและเส้นทางที่พบในขณะที่ตรวจสอบแบบจำลองและการตรวจสอบสัญลักษณ์ต่าง ๆ ตามลำดับ สามารถมีผลต่อขั้นตอนการยืนยัน นอกจากนี้เครื่องมือการยืนยันแบบเป็นทางการทั่วไปใช้ SMT solvers และตัวแก้ปัญหาคำสั่งอื่น ๆ ในชั้นฐานของพวกเขา และตัวแก้ปัญหาเหล่านี้ขึ้นอยู่กับขั้นตอนที่ใช้คำนวณอย่างให้ความสำคัญ

นอกจากนี้ มันไม่ได้เป็นไปได้เสมอ สำหรับผู้ทวนสอบโปรแกรมที่จะกำหนดว่าคุณสมบัติ (ที่บรรยายเป็นสูตรตรรกะ) สามารถได้รับการพอใจหรือไม่ ("ปัญหาการตัดสิน

(เปิดในแท็บใหม่)

") เนื่องจากโปรแกรมอาจไม่สิ้นสุด ดังนั้นจึงอาจเป็นไปไม่ได้ที่จะพิสูจน์คุณสมบัติบางอย่างสําหรับสัญญาแม้ว่าจะระบุไว้อย่างดีก็ตาม

เครื่องมือการตรวจสอบเชิงปฏิบัติสำหรับสัญญาอัจฉริยะบนเอเธอเรียม

ภาษาสำหรับสร้างข้อกำหนดเป็นรูปแบบทางการ

Act: Act ช่วยให้สามารถระบุการอัปเดตการเก็บข้อมูล เงื่อนไขก่อน/หลัง และกฎสัญญา โดยชุดเครื่องมือของมันยังมี proof backends ที่สามารถพิสูจน์คุณสมบัติมากมายผ่าน Coq, SMT solvers หรือ hevm ได้

• GitHub
• (เปิดในแท็บใหม่)
• เอกสาร
• (เปิดในแท็บใหม่)

Scribble - Scribble แปลงหมายเหตุโค้ดในภาษาสเปกิเฟิเคชัน Scribble เป็นข้อคิดที่แน่นอนที่ตรวจสอบข้อกำหนด

• เอกสาร
• (เปิดในแท็บใหม่)

Dafny - Dafny เป็นภาษาโปรแกรมพร้อมทดสอบที่เชื่อมั่นในประกาศระดับสูงเพื่อวิเคราะห์และพิสูจน์ความถูกต้องของโค้ด

• GitHub
• (เปิดในแท็บใหม่)

โปรแกรมตรวจสอบความถูกต้องสำหรับตรวจสอบ

Certora Prover - Certora Prover เป็นเครื่องมือการยืนยันแบบเชิงพิสูจน์โดยอัตโนมัติสำหรับการตรวจสอบความถูกต้องของรหัสในสมาร์ทคอนแทรค มีข้อกำหนดที่เขียนขึ้นใน CVL (ภาษาการยืนยัน Certora), โดยการตรวจจับการละเมิดคุณสมบัติโดยใช้การวิเคราะห์แบบคงที่และการแก้ปัญหาเงื่อนไข

• เว็บไซต์
• (เปิดในแท็บใหม่)
• เอกสารประกอบ
• (เปิดในแท็บใหม่)

Solidity SMTChecker - SMTChecker ของ Solidity เป็นโปรแกรมตรวจสอบแบบมีรูปแบบที่ซ่อนอยู่ที่พอดีกับ SMT (Satisfiability Modulo Theories) และการแก้ปัญหา Horn solving มันยืนยันว่าโค้ดต้นฉบับของสัญญาตรวจสอบรายละเอียดระหว่างกระบวนการคอมไพล์และตรวจสอบสถานะของการละเมิดความปลอดภัย

• GitHub
• (เปิดในแท็บใหม่)

solc-verify - solc-verify เป็นเวอร์ชันที่ขยายของตัวคอมไพเลอร์ Solidity ซึ่งสามารถดำเนินการตรวจสอบแบบเชิงรูปภาษาอัตโนมัติบนโค้ด Solidity โดยใช้ประเภทและการตรวจสอบโปรแกรมแบบโมดูล

• GitHub
• (เปิดในแท็บใหม่)

KEVM - KEVM เป็นเส้นหลักทางประชามาตรของเครื่องมือเสมือนของ Ethereum (EVM) ที่เขียนขึ้นในโครงสร้าง K KEVM สามารถประมวลผลและพิสูจน์บางข้อความที่เกี่ยวข้องกับคุณสมบัติโดยใช้ตรรกะการเข้าถึง

• GitHub
• (เปิดในแท็บใหม่)
• เอกสาร
• (เปิดในแท็บใหม่)

กรอบตรรกะสำหรับการพิสูจน์ทฤษฎี

Isabelle - Isabelle/HOL เป็นผู้ช่วยพิสูจน์ที่ช่วยให้สูตรทางคณิตศาสตร์สามารถแสดงในภาษาที่เป็นทางการและจัดหาเครื่องมือสําหรับการพิสูจน์สูตรเหล่านั้น แอปพลิเคชันหลักคือการพิสูจน์ทางคณิตศาสตร์อย่างเป็นทางการและโดยเฉพาะอย่างยิ่งการตรวจสอบอย่างเป็นทางการซึ่งรวมถึงการพิสูจน์ความถูกต้องของฮาร์ดแวร์คอมพิวเตอร์หรือซอฟต์แวร์และการพิสูจน์คุณสมบัติของภาษาคอมพิวเตอร์และโปรโตคอล

• GitHub
• (เปิดในแท็บใหม่)
• เอกสาร
• (เปิดในแท็บใหม่)

Coq - Coq เป็นตัวพิสูจน์ทฤษฎีแบบโต้ตอบที่ช่วยให้คุณกำหนดโปรแกรมโดยใช้ทฤษฎีและสร้างการพิสูจน์ที่ตรวจสอบได้ด้วยเครื่อง

• GitHub
• (เปิดในแท็บใหม่)
• เอกสาร
• (เปิดในแท็บใหม่)

เครื่องมือที่ใช้การทำสัญลักษณ์เพื่อตรวจพบรูปแบบที่มีช่องโหว่ในสมาร์ทคอนแทร็ค

Manticore - เครื่องมือสำหรับการวิเคราะห์โค้ดบรรทัดคำสั่ง EVM ที่ใช้การสัมพันธ์ในการประมวลผล.

• GitHub
• (เปิดในแท็บใหม่)
• เอกสาร
• (เปิดในแท็บใหม่)

hevm - hevm เป็นเครื่องมือสำหรับการประมวลผลสัญลักษณ์และตรวจสอบความเทียบเท่าสำหรับรหัส EVM

• GitHub
• (เปิดในแท็บใหม่)

Mythril - เครื่องมือการดำเนินการตัวแทนสัญลักษณ์สำหรับตรวจจับช่องโหว่ในสมาร์ทคอนแทรค Ethereum

• GitHub
• (เปิดในแท็บใหม่)
• เอกสาร
• (เปิดในแท็บใหม่)

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกพิมพ์ใหม่จาก [ ]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [**]. If there are objections to this reprint, please contact the Gate Learnทีม และพวกเขาจะจัดการกับมันโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำเกี่ยวกับการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่น ๆ โดยทีม Gate Learn นอกจากที่กล่าวถึงไว้แล้ว ห้ามคัดลอก แจกจ่าย หรือลอกเลียนบทความที่ถูกแปล