ที่มา : Vitalik Buterin

เมื่อวันที่ 20 เมษายน Vitalik Buterin ได้เสนอข้อเสนอที่สำคัญเกี่ยวกับเลเยอร์การดำเนินการ L1 ระยะยาวของ Ethereum บนแพลตฟอร์ม Ethereum Magicians เขาแนะนำให้ใช้สถาปัตยกรรม RISC-V เพื่อแทนที่ EVM (Ethereum Virtual Machine) ที่มีอยู่เป็นภาษาเครื่องเสมือนในการเขียนสัญญาอัจฉริยะ โดยมุ่งหวังที่จะปรับปรุงประสิทธิภาพการทำงานของเลเยอร์การดำเนินการ Ethereum ให้ดีขึ้นอย่างแท้จริง ทำลายข้อจำกัดในการขยายตัวหลักประการหนึ่งในปัจจุบัน และลดความซับซ้อนของเลเยอร์การดำเนินการให้เหลือน้อยที่สุด

Foresight News ได้รวบรวมข้อความเต็มของข้อเสนอเพื่อช่วยให้ผู้อ่านเข้าใจวิสัยทัศน์ด้านเทคโนโลยีนี้ ต่อไปนี้เป็นการรวบรวมข้อเสนอเดิม:

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

แนวคิดหลัก: ใช้ RISC-V แทน EVM ในฐานะภาษาเครื่องเสมือนในการเขียนสัญญาอัจฉริยะ

หมายเหตุสำคัญ:

Nervos CKB VM ได้สร้างบรรทัดฐานและเป็นการ ใช้งาน RISC-V เป็นหลัก

ทำไมต้องทำแบบนี้?

ในระยะสั้น EIP ที่กำลังจะเกิดขึ้น (เช่น รายการการเข้าถึงระดับบล็อก การดำเนินการที่ล่าช้า การจัดเก็บประวัติแบบกระจาย และ EIP-4444 ) จะสามารถแก้ไขปัญหาคอขวดการขยายตัวหลักของ Ethereum L1 ได้ ในระยะกลาง ปัญหาต่างๆ มากมายจะได้รับการแก้ไขผ่านภาวะไร้รัฐสัญชาติและ ZK-EVM ในระยะยาว ปัจจัยจำกัดหลักสำหรับการขยายตัวของ Ethereum L1 จะกลายเป็น:

ฉันจะโต้แย้งว่าการแทนที่ ZK-EVM ด้วย RISC-V สามารถแก้ไขปัญหาคอขวดที่สำคัญใน (2) และ (3) ได้

ตารางต่อไปนี้แสดงจำนวนรอบที่จำเป็นสำหรับแต่ละขั้นตอนของเลเยอร์การดำเนินการ EVM ที่ต้องได้รับการพิสูจน์โดย Succinct ZK-EVM:

คำอธิบายแผนภูมิ: ขั้นตอนหลักที่ใช้เวลานานสี่ขั้นตอนคือ deserialize_inputs, initialize_witness_db, state_root_computation และ block_execution

ในขณะที่ initialize_witness_db และ state_root_computation เกี่ยวข้องกับโครงสร้างสถานะ deserialize_inputs จะเกี่ยวข้องกับกระบวนการแปลงข้อมูลแบบบล็อกและพยานให้เป็นการแสดงภายใน โดยจริงแล้ว มากกว่า 50% นั้นเป็นสัดส่วนตามขนาดของข้อมูลพยาน

ชิ้นส่วนเหล่านี้สามารถปรับให้เหมาะสมได้อย่างมีนัยสำคัญโดยการแทนที่ keccak 16-ary Merkle patricia tree ปัจจุบันด้วย binary tree ที่ใช้ฟังก์ชันแฮชที่พิสูจน์ได้ง่าย โดยใช้ Poseidon เราจึงสามารถ พิสูจน์แฮชได้ 2 ล้านแฮชต่อวินาที บนแล็ปท็อป (เมื่อเปรียบเทียบกับ keccak ที่ทำได้ประมาณ 15,000 แฮชต่อวินาที) นอกจากโพไซดอนยังมีตัวเลือกอื่น ๆ อีกมากมาย โดยทั่วไปแล้ว มีพื้นที่อีกมากสำหรับการเพิ่มประสิทธิภาพของส่วนประกอบเหล่านี้ นอกจากนี้ เราสามารถกำจัด accrue_logs_bloom ได้โดย การลบ bloom

block_executions ที่เหลือคิดเป็นประมาณครึ่งหนึ่งของรอบการพิสูจน์ปัจจุบัน เพื่อให้บรรลุการปรับปรุงประสิทธิภาพการพิสูจน์โดยรวม 100 เท่า จำเป็นต้องเพิ่มประสิทธิภาพการพิสูจน์ EVM อย่างน้อย 50 เท่า วิธีแก้ปัญหาประการหนึ่งก็คือการสร้างการใช้งานพิสูจน์ที่มีประสิทธิภาพมากยิ่งขึ้นสำหรับ EVM อีกวิธีหนึ่งคือการสังเกตว่าตัวพิสูจน์ ZK-EVM ในปัจจุบันพิสูจน์ได้จริงโดยการคอมไพล์ EVM เป็น RISC-V ซึ่งให้ผู้พัฒนาสัญญาอัจฉริยะเข้าถึงเครื่องเสมือน RISC-V โดยตรง

ข้อมูลบางอย่างแสดงให้เห็นว่าในบางกรณีการปรับปรุงประสิทธิภาพอาจเกิน 100 เท่า:

ในการใช้งานจริง เวลาพิสูจน์ที่เหลืออาจถูกใช้ไปกับการดำเนินการพรีคอมไพล์ในปัจจุบันเป็นหลัก หากใช้ RISC-V เป็นเครื่องเสมือนหลัก ตารางก๊าซจะสะท้อนเวลาพิสูจน์จริง และแรงกดดันทางเศรษฐกิจจะกระตุ้นให้ผู้พัฒนาลดการใช้การคอมไพล์ล่วงหน้าที่มีต้นทุนสูง แม้ว่าในตอนนั้นผลกำไรอาจจะไม่มากมายนัก แต่ก็มีเหตุผลหลายประการที่จะเชื่อว่าผลกำไรจะมากมายมหาศาล

(สิ่งที่น่าสังเกตก็คือ เวลาที่ใช้ไปกับ "การดำเนินการ EVM" และ "การดำเนินการอื่นๆ" ใน การดำเนินการ EVM ทั่วไปนั้น ก็ใกล้เคียงกับ 50/50 เช่นกัน ดังนั้นเราจึงเชื่อโดยสัญชาตญาณว่าการลบ EVM ออกจาก "เลเยอร์กลาง" จะนำมาซึ่งผลลัพธ์ที่สำคัญเท่าเทียมกัน)

รายละเอียดการดำเนินการ

มีหลายวิธีในการดำเนินการตามข้อเสนอนี้ โซลูชันที่ก่อให้เกิดการรบกวนน้อยที่สุดคือการรองรับเครื่องเสมือนทั้งสองเครื่องในเวลาเดียวกัน ซึ่งช่วยให้สามารถเขียนสัญญาในเครื่องใดเครื่องหนึ่งได้ สัญญาทั้งสองประเภทสามารถเข้าถึงฟังก์ชันการทำงานเดียวกันได้: พื้นที่เก็บข้อมูลถาวร (SLOAD/SSTORE) ความสามารถในการเก็บยอดคงเหลือ ETH การโทรออก/รับสาย ฯลฯ สัญญา EVM และ RISC-V สามารถเรียกซึ่งกันและกันได้ - จากมุมมองของ RISC-V การเรียกสัญญา EVM นั้นเทียบเท่ากับการดำเนินการเรียกระบบด้วยพารามิเตอร์พิเศษ และสัญญา EVM ที่ได้รับข้อความจะตีความว่าเป็น CALL

แนวทางที่รุนแรงกว่าจากมุมมองของโปรโตคอลจะเป็นการแปลงสัญญา EVM ที่มีอยู่ให้เรียกใช้สัญญาอินเทอร์พรีเตอร์ EVM ที่เขียนใน RISC-V และรันโค้ด EVM ที่มีอยู่ นั่นคือ ถ้าสัญญา EVM มีโค้ด C และล่าม EVM อยู่ที่ที่อยู่ X สัญญานั้นจะถูกแทนที่ด้วยตรรกะระดับสูงสุด ซึ่งเมื่อเรียกจากภายนอกด้วยพารามิเตอร์การเรียก D ก็จะเรียก X และส่งผ่าน (C, D) จากนั้นรอค่าส่งคืนและส่งต่อ หากตัวแปล EVM เรียกสัญญาโดยขอให้รัน CALL หรือ SLOAD/SSTORE สัญญาจะดำเนินการดังกล่าว

ทางเลือกที่ 2 คือการยอมรับทางเลือกที่สอง แต่สนับสนุนแนวคิดของ "ล่ามเครื่องเสมือน" อย่างชัดเจนผ่านโปรโตคอล และกำหนดให้ต้องเขียนตรรกะใน RISC-V EVM จะเป็นการนำไปใช้งานครั้งแรก โดยจะมีการรองรับภาษาอื่นๆ ในอนาคต (Move คือตัวเลือกที่เป็นไปได้)

ข้อได้เปรียบหลักของตัวเลือกที่สองและสามก็คือคุณสมบัติเหล่านี้ทำให้การระบุชั้นการดำเนินการง่ายขึ้นมาก เนื่องจากการลดความซับซ้อนในระดับเพิ่มขึ้น เช่น การลบ SELFDESTRUCT ออกไปนั้นทำได้ยาก ดังนั้นแนวทางนี้จึงอาจเป็นเส้นทางการลดความซับซ้อนเพียงทางเดียวที่ใช้ได้จริง Tinygrad ปฏิบัติตามกฎที่เข้มงวดคือ " ไม่ควรมีโค้ดเกิน 10,000 บรรทัด" และเลเยอร์พื้นฐานของ บล็อคเชนที่เหมาะสมที่สุดจะต้องสามารถปฏิบัติตามข้อจำกัดนี้ได้อย่างง่ายดาย และปรับปรุงให้มีประสิทธิภาพยิ่งขึ้น โครงการ Beam Chain สัญญาว่าจะทำให้เลเยอร์ฉันทามติของ Ethereum เรียบง่ายขึ้นอย่างมาก และการเปลี่ยนแปลงครั้งใหญ่ครั้งนี้อาจเป็นเส้นทางเดียวที่เป็นไปได้ในการปรับปรุงที่คล้ายคลึงกันในเลเยอร์การดำเนินการ