ข้อเสนอเลเยอร์การดำเนินการ L1 ระยะยาวของ Vitalik: แทนที่ EVM ด้วย RISC-V

ชื่อเรื่องเดิม: ข้อเสนอเกี่ยวกับเลเยอร์การดำเนินการ L1 ระยะยาว: แทนที่ EVM ด้วย RISC-V

แหล่งที่มาเดิม: Vitalik Buterin

คำแปลต้นฉบับ: KarenZ, Foresight News

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

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

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

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

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

· แนวคิดต่างๆ เช่น ระบบบัญชี การโทรข้ามสัญญา และพื้นที่จัดเก็บข้อมูล จะถูกเก็บรักษาไว้อย่างสมบูรณ์ การแยกส่วนเหล่านี้ใช้ได้ดีและนักพัฒนาก็คุ้นเคยกับสิ่งเหล่านี้แล้ว โอปโค้ดเช่น SLOAD, SSTORE, BALANCE, CALL ฯลฯ จะถูกแปลงเป็นการเรียกใช้ระบบ RISC-V

· ในโหมดนี้ สัญญาอัจฉริยะสามารถเขียนเป็นภาษา Rust ได้ แต่ฉันคาดว่านักพัฒนาส่วนใหญ่จะยังคงเขียนสัญญาในภาษา Solidity (หรือ Vyper) ต่อไป ซึ่งจะถูกปรับให้เหมาะกับ RISC-V ในฐานะแบ็กเอนด์ใหม่ เนื่องจากสมาร์ทคอนแทร็กต์ที่เขียนใน Rust นั้นอ่านได้น้อยกว่า ขณะที่ Solidity และ Vyper นั้นชัดเจนและอ่านง่ายกว่า ประสบการณ์การพัฒนาอาจได้รับผลกระทบเพียงเล็กน้อยและนักพัฒนาอาจไม่สังเกตเห็นการเปลี่ยนแปลงด้วยซ้ำ

· สัญญา EVM ฉบับเดิมจะยังคงมีผลบังคับใช้ต่อไป และเข้ากันได้แบบสองทางอย่างสมบูรณ์กับสัญญา RISC-V ฉบับใหม่ มีหลายวิธีในการบรรลุสิ่งนี้ ซึ่งจะอธิบายโดยละเอียดในบทความนี้

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

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

1. เสถียรภาพของการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลและโปรโตคอลการจัดเก็บประวัติ

2. ความจำเป็นในการรักษาตลาดการผลิตบล็อกให้มีการแข่งขัน

3. ความสามารถในการพิสูจน์ของ ZK-EVM

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

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

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

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

(สิ่งที่น่าสังเกตก็คือ เวลาที่ใช้ไปกับ "การดำเนินการ 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 สัญญาจะดำเนินการดังกล่าว

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

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

ลิงก์ต้นฉบับ

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia