บทความนี้มาจาก: Vitalik ผู้ร่วมก่อตั้ง Ethereum
เรียบเรียงโดย Odaily Planet Daily ( @OdailyChina )
แปลโดย อาซึมะ ( @azuma_eth )
ในโพสต์นี้ ฉันจะเสนอแนวคิดสุดขั้วสำหรับอนาคตของเลเยอร์การดำเนินการของ Ethereum ซึ่งมีความทะเยอทะยานพอๆ กับแผน Beam Chain สำหรับเลเยอร์ฉันทามติ เป้าหมายของการริเริ่มนี้คือการปรับปรุงประสิทธิภาพของเลเยอร์การดำเนินการของ Ethereum อย่างมีนัยสำคัญ โดยแก้ไขปัญหาคอขวดการปรับขนาดหลักประการหนึ่ง ขณะเดียวกันก็ลดความซับซ้อนของเลเยอร์การดำเนินการให้เหลือน้อยที่สุด จริงๆ แล้ว นี่อาจเป็นวิธีเดียวที่จะบรรลุถึงการลดความซับซ้อนได้
แนวคิดหลักของบทความนี้คือการแทนที่ EVM ด้วย RISC-V ซึ่งเป็นภาษาเครื่องเสมือนสำหรับสัญญาอัจฉริยะ
หมายเหตุสำคัญ:
แนวคิดต่างๆ เช่น บัญชี การโทรข้ามสัญญา และการจัดเก็บข้อมูล จะถูกเก็บรักษาไว้อย่างสมบูรณ์ การแยกส่วนเหล่านี้ใช้ได้ดีและนักพัฒนาก็คุ้นเคยกับการใช้มัน โอปโค้ดเช่น SLOAD, SSTORE, BALANCE, CALL ฯลฯ จะกลายเป็นการเรียกใช้ระบบ RISC-V
นักพัฒนาสามารถเลือก Solidity หรือ Vyper ได้ แม้ว่าในเชิงทฤษฎีแล้วสัญญาอัจฉริยะสามารถเขียนด้วย Rust ได้ แต่คาดว่านักพัฒนาส่วนใหญ่จะยังคงใช้ Solidity (หรือ Vyper) ซึ่งจะถูกปรับให้เข้ากับ RISC-V เป็นเป้าหมายการคอมไพล์แบ็กเอนด์ นั่นเป็นเพราะสัญญาอัจฉริยะที่เขียนด้วย Rust จะอ่านได้น้อยกว่า ในขณะที่ Solidity และ Vyper นั้นเข้าใจได้ง่ายกว่า ประสบการณ์การพัฒนาแทบจะไม่เปลี่ยนแปลงเลย และนักพัฒนาอาจไม่รู้สึกถึงความแตกต่างเลย
สัญญาใหม่และเก่าจะทำงานร่วมกันได้สองทาง สัญญา EVM แบบดั้งเดิมจะยังคงดำเนินต่อไปและทำงานร่วมกับสัญญา RISC-V ฉบับใหม่ได้อย่างสมบูรณ์ วิธีการใช้งานที่เฉพาะเจาะจงจะอธิบายอย่างละเอียดในภายหลัง
มีกรณีตัวอย่างอยู่แล้ว: Nervos CKB VM เป็นการใช้งานบนพื้นฐาน RISC-V
เหตุใดจึงจำเป็นต้องมีการเปลี่ยนแปลงนี้?
ในระยะสั้น ปัญหาคอขวดหลักของการขยาย Ethereum Layer 1 จะได้รับการแก้ไขผ่าน EIP ที่กำลังจะมีขึ้น (เช่น รายการการเข้าถึงระดับบล็อก การดำเนินการที่ล่าช้า การจัดเก็บประวัติแบบกระจาย และ EIP-4444) ในระยะกลางเราจะแก้ไขปัญหาได้มากขึ้นผ่านภาวะไร้รัฐสัญชาติและ ZK-EVM แต่ในระยะยาว ปัจจัยหลักที่จำกัดการขยายตัวของ Ethereum Layer 1 จะกลายเป็น:
การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลและความเสถียรของโปรโตคอลการจัดเก็บข้อมูลในประวัติศาสตร์
ความจำเป็นในการรักษาตลาดการแข่งขันสำหรับการผลิตแบบบล็อก
ความสามารถในการพิสูจน์ของ ZK-EVM
บทความนี้จะแสดงให้เห็นว่า การแทนที่ ZK-EVM ด้วย RISC-V สามารถทะลุผ่านจุดคอขวดสำคัญในข้อ 2 และ 3 ได้
ต่อไปนี้เป็นตารางสถิติจำนวนรอบที่ Succinct ZK-EVM จำเป็นต้องใช้เพื่อพิสูจน์แต่ละลิงก์ของเลเยอร์การดำเนินการ EVM:
ลิงก์หลักที่ใช้เวลานานสี่รายการ ได้แก่: deserialize_inputs (การยกเลิกการทำซีเรียลไลซ์ข้อมูล), initialize_witness_db (การเริ่มต้นฐานข้อมูลพยาน), state_root_computation (การคำนวณรูทสถานะ) และ block_execution (การดำเนินการแบบบล็อก)
“การเริ่มต้นฐานข้อมูลพยาน” และ “การคำนวณรากสถานะ” ล้วนเกี่ยวข้องกับโครงสร้างสถานะ ในขณะที่ “การยกเลิกการทำข้อมูลให้เป็นอนุกรม” หมายความถึงกระบวนการแปลงข้อมูลแบบบล็อกและพยานเป็นการแสดงภายใน ดังนั้น จริงๆ แล้วมากกว่าร้อยละ 50 ของเวลาเกี่ยวข้องกับขนาดของข้อมูลพยาน
ขั้นตอนเหล่านี้สามารถปรับให้เหมาะสมได้อย่างมีนัยสำคัญโดยการแทนที่ keccak 16-ary Merkle patricia tree ในปัจจุบันด้วย binary tree ที่ใช้ฟังก์ชันแฮชที่เป็นมิตรต่อหลักฐาน หากเราใช้ Poseidon เราจะสามารถพิสูจน์แฮชได้ 2 ล้านแฮชต่อวินาทีบนแล็ปท็อป (เมื่อเทียบกับ keccak ที่พิสูจน์ได้ประมาณ 15,000 แฮชต่อวินาที) นอกจาก โพไซดอน ยังมีตัวเลือกอื่นอีกมากมาย โดยรวมแล้ว มีโอกาสที่จะลดเวลาที่ใช้ในขั้นตอนเหล่านี้ได้อย่างมาก นอกจากนี้ เราสามารถลดความซับซ้อนของกระบวนการลงได้อีกโดยการลบ accrue_logs_bloom
ขณะนี้เหลือเพียง การดำเนินการแบบบล็อก เท่านั้น ซึ่งใช้เวลาประมาณครึ่งหนึ่งของรอบการพิสูจน์ปัจจุบัน หากเราต้องการเพิ่มประสิทธิภาพการพิสูจน์โดยรวม 100 เท่า เราจะต้องเพิ่มประสิทธิภาพการพิสูจน์ EVM อย่างน้อย 50 เท่า มีสองเส้นทาง: หนึ่งคือ พยายามสร้างการใช้งาน EVM ที่มีประสิทธิภาพมากขึ้นเพื่อลดรอบการพิสูจน์ อีกวิธีหนึ่งคือให้ผู้พัฒนาสามารถใช้งานเครื่องเสมือน RISC-V ที่ได้รับการนำมาใช้ใน ZK-EVM โดยตรง
ข้อมูลบางส่วนแสดงให้เห็นว่าประสิทธิภาพสามารถปรับปรุงได้มากกว่า 100 เท่าในสถานการณ์บางกรณี:
ในทางปฏิบัติ เวลาในการพิสูจน์ที่เหลือส่วนใหญ่จะถูกใช้ไปกับการคอมไพล์ล่วงหน้า หากกำหนด RISC-V ให้เป็นเครื่องเสมือนหลัก กลไกค่าธรรมเนียมแก๊สจะสะท้อนเวลาพิสูจน์จริง และแรงกดดันทางเศรษฐกิจจะกระตุ้นให้ผู้พัฒนาลดการใช้การคอมไพล์ล่วงหน้าที่มีต้นทุนสูง แม้ว่าผลตอบแทนที่แท้จริงอาจจะไม่ดีเท่ากับค่าทางทฤษฎี แต่คาดว่ายังคงมีความสำคัญมาก
เป็นเรื่องที่น่าสังเกตว่ามีการแบ่ง EVM และ ลิงก์อื่นๆ ในการดำเนินการ EVM ปกติในอัตรา 50/50 และเราเชื่อโดยสัญชาตญาณว่าการลบ EVM ออกจาก เลเยอร์กลาง ควรส่งผลให้ประสิทธิภาพดีขึ้นในลักษณะเดียวกัน
การนำไปปฏิบัติ
มีหลายวิธีในการดำเนินการตามข้อเสนอข้างต้น
แนวทางที่สร้างความวุ่นวายน้อยที่สุดคือการรองรับทั้งเครื่องเสมือนและอนุญาตให้เขียนสัญญาในเครื่องเสมือนทั้งสองเครื่อง สัญญาทั้งสองประเภทสามารถเข้าถึงฟังก์ชันการทำงานเดียวกันได้: พื้นที่เก็บข้อมูลถาวร (SLOAD/SSTORE), การจัดการยอดคงเหลือ ETH, การโทรออกและรับสาย ฯลฯ สัญญา EVM และ RISC-V สามารถทำงานร่วมกันได้อย่างอิสระ: การเรียกสัญญา EVM จากมุมมองของ RISC-V จะถูกมองว่าเป็นการเรียกระบบ (syscall) ที่มีพารามิเตอร์พิเศษ ในขณะที่สัญญา EVM ที่รับการเรียกจะแยกวิเคราะห์การเรียกดังกล่าวเป็นคำสั่ง CALL ปกติ
โซลูชันที่รุนแรงกว่าคือการแปลงสัญญา EVM ที่มีอยู่ให้เรียกใช้สัญญาอินเทอร์พรีเตอร์ EVM ที่เขียนใน RISC-V เพื่อดำเนินการโค้ด EVM ดั้งเดิม โดยเฉพาะอย่างยิ่ง หากถือว่าสัญญา EVM มีโค้ด C และล่าม EVM อยู่ในที่อยู่ X สัญญาจะถูกแทนที่ด้วยตรรกะระดับสูงสุด: เมื่อมีการเริ่มการเรียกภายนอกด้วยพารามิเตอร์การเรียก D ตรรกะจะส่งคำขอ (C, D) ไปยัง X รอค่าส่งคืน และส่งต่อคำขอนั้น หากตัวแปล EVM เองจำเป็นต้องเรียกสัญญาเพื่อดำเนินการต่างๆ เช่น CALL, SLOAD หรือ SSTORE สัญญาจะตอบสนองโดยตรง
วิธีแก้ปัญหาแบบประนีประนอมคือสร้างจากวิธีแก้ปัญหาที่สองและสนับสนุนแนวคิดของ ล่ามเครื่องเสมือน โดยชัดเจนผ่านเลเยอร์โปรโตคอล นั่นก็คือ ตรรกะของล่ามจะต้องเขียนใน RISC-V EVM จะเป็นล่ามอย่างเป็นทางการตัวแรก และอาจจะมีการนำล่ามประเภทอื่นๆ (เช่น ล่ามภาษา Move) มาใช้ในอนาคต
ข้อได้เปรียบหลักของตัวเลือกที่สองและสามก็คือคุณสมบัติเหล่านี้ทำให้ข้อกำหนดของชั้นการดำเนินการนั้นง่ายยิ่งขึ้นมาก เนื่องจากแม้แต่การลดความซับซ้อนในระดับเพิ่มขึ้น เช่น การลบ SELFDESTRUCT ออกไป ถือว่าทำได้ยาก การเปลี่ยนแปลงดังกล่าวอาจเป็นวิธีเดียวที่เป็นไปได้ในการบรรลุถึงการลดความซับซ้อนนั้น โครงการ Tinygrad กำหนดอย่างเคร่งครัดว่าจำนวนโค้ดจะไม่เกิน 10,000 บรรทัด เลเยอร์พื้นฐานบล็อคเชนในอุดมคติควรมีความเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ โครงการ Beam Chain ชี้ทางไปสู่การลดความซับซ้อนของเลเยอร์ฉันทามติของ Ethereum และความก้าวหน้าที่คล้ายคลึงกันในเลเยอร์การดำเนินการสามารถทำได้โดยการเปลี่ยนแปลงพื้นฐานดังกล่าวเท่านั้น
