Vitalik ข้อเสนอใหม่: ใช้ RISC-V แทน EVM ปัจจุบัน

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

ความคิด: ใช้ RISC-V แทน EVM เป็นภาษาที่ใช้ในการเขียนสัญญาอัจฉริยะ (หมายเหตุผู้แปล: RISC-V หมายถึง สถาปัตยกรรมชุดคำสั่งเปิดที่สร้างขึ้นจากหลักการของการคำนวณแบบชุดคำสั่งที่ลดขนาด ซึ่ง V หมายถึง รุ่นที่ห้าของ RISC)

การชี้แจงที่สำคัญ:

• บัญชี, การเรียกข้ามสัญญา, การจัดเก็บ และแนวคิดอื่นๆ จะยังคงเหมือนเดิมอย่างสมบูรณ์ การทำงานของนามธรรมเหล่านี้ทำได้ดีมาก และนักพัฒนาก็ชินกับมันแล้ว รหัสปฏิบัติการเช่น SLOAD, SSTORE, BALANCE, CALL จะกลายเป็นการเรียกใช้ระบบ RISC-V.
• ในโลกเช่นนี้ สัญญาอัจฉริยะสามารถเขียนด้วย Rust ได้ แต่ฉันคาดว่าพัฒนากรส่วนใหญ่จะยังคงเขียนสัญญาอัจฉริยะด้วย Solidity (หรือตัว Vyper) ซึ่งจะปรับให้เข้ากับการเพิ่ม RISC-V เป็นแบ็คเอนด์ นี่เป็นเพราะสัญญาอัจฉริยะที่เขียนด้วย Rust นั้นมีความซับซ้อนจริง ๆ ในขณะที่ความสามารถในการอ่านของ Solidity และ Vyper สูงกว่ามาก บางทีการเปลี่ยนแปลงของ devex อาจจะเล็กน้อย พัฒนากรอาจจะไม่สังเกตเห็นการเปลี่ยนแปลงนี้แทบเลย.
• สัญญา EVM รุ่นเก่าจะยังคงมีผล และจะสามารถทำงานร่วมกันได้อย่างเต็มที่กับสัญญา RISC-V รุ่นใหม่ มีหลายวิธีในการทำเช่นนี้ ซึ่งฉันจะอธิบายในภายหลังในบทความนี้.

ตัวอย่างหนึ่งคือ Nervos CKB VM ซึ่งพื้นฐานแล้วคือ RISC-V.

ทำไมถึงทำแบบนี้?

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

• ความเสถียรของการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลและโปรโตคอลการจัดเก็บประวัติ
• หวังว่าจะรักษาความสามารถในการแข่งขันในตลาดการผลิตบล็อก
• ความสามารถในการตรวจสอบ ZK-EVM

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

นี่คือตารางจำนวนรอบสำหรับการพิสูจน์ส่วนต่างๆ ของชั้นการดำเนินการ EVM ที่ใช้ Succinct ZK-EVM:

! nsRqhscTyRR2vPvAOgUE58HVgFHuLUgGxTescWwT.jpeg

มีสี่ส่วนที่ใช้เวลามาก: deserialize_inputs, initialize_witness_db, state_root_computation และ block_execution

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

ชิ้นส่วนเหล่านี้สามารถปรับให้เหมาะสมได้อย่างมากโดยแทนที่ต้น keccak 16 meta Merkle patricia ปัจจุบันด้วยต้นไม้ไบนารีที่ใช้ฟังก์ชันแฮชที่เป็นมิตรกับการพิสูจน์ หากเราใช้โพไซดอนเราสามารถพิสูจน์แฮช 2 ล้านแฮชต่อวินาทีบนแล็ปท็อป (ในขณะที่ keccak อยู่ที่ประมาณ 15,000 แฮชต่อวินาที) มีตัวเลือกอื่น ๆ อีกมากมายนอกเหนือจากโพไซดอน สรุปแล้วเรามีโอกาสที่จะลดส่วนประกอบเหล่านี้ลงอย่างมาก เป็นโบนัสเราสามารถกําจัดการสะสม \ _logs \ _bloom โดยการกําจัดบาน

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

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

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

(โดยบังเอิญ การแบ่งประมาณ 50/50 ระหว่าง “EVM” และ “สิ่งอื่น ๆ” ก็ปรากฏใน EVM execution ปกติ เราคาดการณ์อย่างมีสติว่า ผลประโยชน์ที่ได้จากการลบ EVM ในฐานะ “คนกลาง” ควรจะมีขนาดเท่ากัน)

รายละเอียดการใช้งาน

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

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

เส้นทางกลางคือการใช้ตัวเลือกที่สอง แต่สร้างฟังก์ชันโปรโตคอลที่ชัดเจนสำหรับมัน - โดยพื้นฐานแล้วให้แนวคิดของ “เครื่องยนต์เสมือน” เป็นเกณฑ์ และต้องการให้ตรรกะของมันเขียนด้วย RISC-V EVM จะเป็นตัวแรก แต่ก็อาจมีตัวอื่น ๆ (เช่น Move อาจเป็นผู้สมัคร)

ประโยชน์ที่สําคัญของข้อเสนอที่สองและสามคือพวกเขาลดความซับซ้อนของข้อกําหนดชั้นผู้บริหาร - ในความเป็นจริง IDEA นี้อาจเป็นวิธีเดียวที่จะไปได้เนื่องจากแม้แต่ความเรียบง่ายที่ก้าวหน้าเช่นการลบการทําลายตนเองนั้นยากมาก Tinygrad มีกฎที่เข้มงวดว่าจํานวนรหัสไม่ควรเกิน 10,000 บรรทัด เลเยอร์ฐานบล็อกเชนที่เหมาะสมที่สุดควรสามารถปรับให้เข้ากับขอบเขตเหล่านี้ได้ดีหรือเล็กลง ความพยายามของ BeamChain ให้คํามั่นสัญญามากมายในการทําให้ชั้นฉันทามติของ Ethereum ง่ายขึ้นอย่างมาก แต่สําหรับฝ่ายบริหารการเปลี่ยนแปลงที่รุนแรงเช่นนี้อาจเป็นวิธีเดียวที่เป็นไปได้ที่จะบรรลุผลประโยชน์ที่คล้ายคลึงกัน