ความคิดเห็น: EVM โดยไม่ต้องกำหนดเวอร์ชัน

หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: Ethfans)หมายเหตุบรรณาธิการ: บทความนี้มาจาก

ผู้ที่ชื่นชอบ Ethereum (ID: Ethfans)

ผู้เขียน: Wei Tang แปล: A Jian พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต

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

ในบทความนี้ ฉันจะสำรวจคำถามนี้และบันทึกคำอธิบายทางเทคนิคและปรัชญาการออกแบบที่พัฒนาขึ้นจากคำถามนี้

ชื่อเรื่องรอง

เว็บไม่มีเวอร์ชันและมีมานานหลายทศวรรษแล้ว ดังนั้นฉันคิดว่าเราต้องการสร้าง EVM ที่ไม่มีความแตกต่างของเวอร์ชัน

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

ชื่อเรื่องรอง

opcode ไม่ถูกต้อง

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

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

• ข้าม bytecode ของรหัส

• หากรหัสเป็นรหัส opcode PUSH(n) ให้ข้าม n ไบต์ถัดไป

มิฉะนั้นจะเกิดข้อผิดพลาด (กับดัก)

การตรวจสอบข้างต้นค่อนข้างคล้ายกับการตรวจสอบปลายทางข้าม โปรดทราบว่าสำหรับข้อยกเว้น เราใช้ "กับดัก" ที่นี่ ซึ่งเราจะอธิบายรายละเอียดด้านล่าง

ชื่อเรื่องรอง

โพรบคุณลักษณะ

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

• opcode นี้ใช้อาร์กิวเมนต์สแต็ก จะตรวจสอบว่าพารามิเตอร์อยู่ระหว่าง 0 ถึง 2^8 หรือไม่ และจับข้อผิดพลาดหากไม่ใช่

หากไม่สนับสนุนอาร์กิวเมนต์ (ตีความว่าเป็น opcode) ให้กด 0x0 กลับเข้าไปในสแต็ก หรือกด 0x1

ข้อยกเว้นและกับดัก

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

ชื่อเรื่องรอง