บทความนี้มาจาก: ผู้พัฒนา Ethereum levochka.eth
รวบรวมโดย Odaily Planet Daily ( @OdailyChina ); แปลโดย อาซึมะ ( @azuma_eth )
หมายเหตุบรรณาธิการ:
เมื่อวานนี้ Vitalik ผู้ก่อตั้งร่วมของ Ethereum ได้เผยแพร่บทความสุดโต่งเกี่ยวกับการอัปเกรดเลเยอร์การดำเนินการของ Ethereum (ดู “ บทความใหม่สุดโต่งของ Vitalik: การขยายเลเยอร์การดำเนินการต้องมี ‘ความก้าวหน้า’ EVM จะต้องทำซ้ำในอนาคต ”) บทความกล่าวถึงความหวัง ในการใช้ RISC-V เพื่อแทนที่ EVM ในฐานะภาษาเครื่องเสมือนสำหรับสัญญาอัจฉริยะ
ทันทีที่บทความนี้ได้รับการเผยแพร่ ก็ทำให้เกิดความวุ่นวายในชุมชนนักพัฒนา Ethereum ทันที และผู้นำทางเทคนิคหลายคนก็แสดงความคิดเห็นที่แตกต่างกันเกี่ยวกับแผนดังกล่าว ไม่นานหลังจากบทความได้รับการเผยแพร่ levochka.eth ซึ่งเป็นผู้พัฒนา Ethereum ชั้นนำ ได้เขียนบทความยาวด้านล่างข้อความดั้งเดิมเพื่อหักล้างมุมมองของ Vitalik เขาเชื่อว่า Vitalik สันนิษฐานไม่ถูกต้องเกี่ยวกับระบบพิสูจน์และประสิทธิภาพการทำงานของระบบ และ RISC-V ไม่สามารถนำ ความสามารถในการปรับขนาด และ ความสามารถในการบำรุงรักษา เข้ามาพิจารณาได้ และอาจไม่ใช่ตัวเลือกที่ดีที่สุด
ต่อไปนี้เป็นเนื้อหาต้นฉบับของ levochka.eth แปลโดย Odaily Planet Daily
ขอร้องอย่าทำแบบนี้.
แผนนี้ไม่สมเหตุสมผลเนื่องจากคุณตั้งสมมติฐานที่ไม่ถูกต้องเกี่ยวกับระบบพิสูจน์และประสิทธิภาพของมัน
การตรวจสอบสมมติฐาน
เท่าที่ฉันเข้าใจ ข้อโต้แย้งหลักสำหรับแนวทางนี้คือ ความสามารถในการปรับขนาด และ ความสามารถในการบำรุงรักษา
ก่อนอื่น ผมอยากหารือเรื่องการบำรุงรักษา
ในความเป็นจริง RISC-V zk-VM ทั้งหมดต้องใช้ การคอมไพล์ล่วงหน้า เพื่อจัดการการดำเนินการที่ต้องใช้การคำนวณเข้มข้น รายการ SP 1 ที่คอมไพล์ไว้ล่วงหน้าสามารถพบได้ในเอกสารประกอบของ Succinct และคุณจะพบว่าเอกสารดังกล่าวครอบคลุมโอปโค้ด เชิงคำนวณ ที่สำคัญเกือบทั้งหมดใน EVM
ดังนั้น การปรับเปลี่ยนทั้งหมดต่อการเข้ารหัสแบบดั้งเดิมของชั้นฐานจึงต้องมีการเขียนและตรวจสอบ วงจร ใหม่สำหรับการคอมไพล์ล่วงหน้าเหล่านี้ ซึ่งถือเป็นข้อจำกัดที่ร้ายแรง
อันที่จริงแล้ว หากประสิทธิภาพดีเพียงพอ การบำรุงรักษาส่วนที่ ไม่ใช่ EVM ของไคลเอนต์การดำเนินการก็อาจจะทำได้ค่อนข้างง่าย ฉันไม่แน่ใจว่าประสิทธิภาพจะดีพอหรือไม่ แต่ฉันมีความมั่นใจในส่วนนี้น้อยลงด้วยเหตุผลดังต่อไปนี้:
การคำนวณต้นไม้สถานะ สามารถเร่งความเร็วได้อย่างมากด้วยการคอมไพล์ล่วงหน้าที่เป็นมิตร (เช่น Poseidon)
แต่ยังไม่ชัดเจนว่าสามารถดำเนินการ deserialization ได้อย่างสวยงามและบำรุงรักษาได้หรือไม่
นอกจากนี้ยังมีรายละเอียดที่ยุ่งยากบางอย่าง (เช่น การวัดก๊าซและการตรวจสอบต่างๆ) ที่อาจอยู่ใน เวลาการประเมินบล็อก แต่จริงๆ แล้วควรจัดอยู่ในประเภทชิ้นส่วนที่ ไม่ใช่ EVM และชิ้นส่วนเหล่านี้มักจะมีแนวโน้มที่จะได้รับแรงกดดันในการบำรุงรักษามากกว่า
ถัดไปคือส่วนที่เกี่ยวกับความสามารถในการปรับขนาด
ฉันจำเป็นต้องย้ำอีกครั้งว่า ไม่มีทางที่ RISC-V จะสามารถจัดการเวิร์กโหลด EVM ได้โดยไม่ต้องใช้การคอมไพล์ล่วงหน้า แน่นอนว่าไม่
ดังนั้น คำชี้แจงในบทความดั้งเดิมที่ว่า เวลาในการพิสูจน์ครั้งสุดท้ายจะถูกควบคุมโดยการดำเนินการพรีคอมไพล์ในปัจจุบัน แม้จะถูกต้องในทางเทคนิค แต่ก็เป็นการมองโลกในแง่ดีเกินไป โดยถือว่าจะไม่มีการพรีคอมไพล์ในอนาคต ในขณะที่ในความเป็นจริง (ในสถานการณ์จำลองอนาคตนี้) พรีคอมไพล์จะยังคงมีอยู่และสอดคล้องอย่างสมบูรณ์กับโอปโค้ดที่ต้องใช้การประมวลผลหนักใน EVM (เช่น การลงนาม การแฮช และการดำเนินการแอนะล็อกเชิงตัวเลขจำนวนมากที่อาจเกิดขึ้นได้)
เมื่อพิจารณาตัวอย่าง Fibonacci แล้ว เป็นเรื่องยากที่จะตัดสินโดยไม่ลงรายละเอียดในระดับต่ำมาก แต่จุดแข็งของ Fibonacci มาจาก:
ความแตกต่างระหว่าง “การตีความ” และ “ค่าใช้จ่ายในการดำเนินการ”
การคลี่ลูปออก (ลด การควบคุมการไหล สำหรับ RISC-V ไม่แน่ใจว่า Solidity สามารถทำสิ่งนี้ได้หรือไม่ แต่แม้ว่าโอปโค้ดเพียงอันเดียวก็ยังสร้างการควบคุมการไหล/การเข้าถึงหน่วยความจำมากมายเนื่องจากภาระในการตีความ)
ใช้ชนิดข้อมูลที่เล็กกว่า
ฉันอยากจะชี้ให้เห็นที่นี่ว่าเพื่อให้ได้เปรียบในข้อ 1 และ 2 จะต้องกำจัด ภาระในการตีความ สิ่งนี้สอดคล้องกับแนวคิดของ RISC-V แต่ไม่ใช่ RISC-V ที่เรากำลังพูดถึงอยู่ในปัจจุบัน แต่เป็น RISC-V ที่คล้ายคลึงกัน ซึ่งจำเป็นต้องมีความสามารถเพิ่มเติมบางอย่าง เช่น รองรับแนวคิดของสัญญา
ปัญหามาถึงแล้ว
ดังนั้นก็มีปัญหาอยู่บ้างตรงนี้
หากต้องการปรับปรุงความสามารถในการบำรุงรักษา คุณต้องมี RISC-V (พร้อมการคอมไพล์ล่วงหน้า) ที่สามารถคอมไพล์ EVM ได้ ซึ่งนี่เป็นสถานการณ์พื้นฐานในปัจจุบัน
การปรับปรุงความสามารถในการปรับขนาดต้องอาศัยสิ่งที่แตกต่างไปจากเดิมอย่างสิ้นเชิง สถาปัตยกรรมใหม่ เช่น RISC-V อาจเข้าใจแนวคิดของ สัญญา เข้ากันได้กับข้อจำกัดของรันไทม์ Ethereum และสามารถรันโค้ดสัญญาโดยตรงได้ (โดยไม่มี ค่าใช้จ่ายในการตีความ)
ตอนนี้ฉันคิดว่าคุณหมายถึงกรณีที่สอง (เพราะว่าส่วนที่เหลือของโพสต์ดูเหมือนจะบอกเป็นนัยเช่นนั้น) ฉันควรแจ้งให้คุณทราบว่าโค้ดทั้งหมดนอกสภาพแวดล้อมนี้จะยังคงเขียนด้วยภาษา RISC-V zkVM ปัจจุบัน ซึ่งมีผลกระทบต่อการบำรุงรักษาอย่างมีนัยสำคัญ
ความเป็นไปได้อื่น ๆ
เราสามารถคอมไพล์ไบต์โค้ดจากโอปโค้ด EVM ระดับสูงได้ คอมไพเลอร์มีหน้าที่รับผิดชอบในการทำให้แน่ใจว่าโปรแกรมที่สร้างขึ้นรักษาค่าคงที่ไว้ เช่น การป้องกัน สแต็กโอเวอร์โฟลว์ ฉันอยากเห็นการสาธิตนี้ใน EVM แบบวานิลลา สามารถจัดทำ SNARK ที่รวบรวมอย่างถูกต้องพร้อมกับคำแนะนำการปรับใช้สัญญาได้
เราสามารถสร้าง หลักฐานอย่างเป็นทางการ ว่าค่าคงที่บางประการเป็นจริงได้ เท่าที่ฉันทราบ แนวทางนี้ (แทนที่จะเป็น การจำลองเสมือน) ถูกใช้ในบริบทเบราว์เซอร์บางส่วนแล้ว โดยการสร้าง SNARK ของการพิสูจน์อย่างเป็นทางการนี้ คุณสามารถบรรลุผลลัพธ์ที่คล้ายคลึงกัน
แน่นอนว่าทางเลือกที่ง่ายที่สุดคือ ลงมือทำเลย
การสร้าง MMU แบบ โซ่ ขั้นต่ำ
คุณอาจนัยถึงเรื่องนี้ในโพสต์ของคุณ แต่ขอเตือนคุณว่า หากคุณต้องการกำจัดภาระงานในการจำลองเสมือน คุณจะต้องดำเนินการโค้ดที่คอมไพล์แล้วโดยตรง ซึ่งหมายความว่าคุณต้องป้องกันไม่ให้สัญญา (ซึ่งตอนนี้เป็นโปรแกรมที่ปฏิบัติการได้) เขียนลงในหน่วยความจำเคอร์เนล (การใช้งานที่ไม่ใช่ EVM)
ดังนั้นเราจึงต้องการ หน่วยจัดการหน่วยความจำ (MMU) บางชนิด กลไกการเพจของคอมพิวเตอร์แบบดั้งเดิมอาจไม่จำเป็นเนื่องจากพื้นที่หน่วยความจำ ทางกายภาพ แทบจะไม่มีที่สิ้นสุด MMU นี้ควรมีความคล่องตัวมากที่สุดเท่าที่จะเป็นไปได้ ( เนื่องจากอยู่ที่ระดับการแยกย่อยเดียวกันกับสถาปัตยกรรมนั้นเอง ) แต่ฟังก์ชันการทำงานบางอย่าง (เช่น การทำธุรกรรมแบบอะตอมมิก ) อาจถูกย้ายไปยังเลเยอร์นี้
ณ จุดนี้ EVM ที่พิสูจน์ได้จะกลายเป็นโปรแกรมเคอร์เนลที่ทำงานบนสถาปัตยกรรมนี้
RISC-V อาจไม่ใช่ตัวเลือกที่ดีที่สุด
ที่น่าสนใจคือ ภายใต้เงื่อนไขทั้งหมดนี้ สถาปัตยกรรมชุดคำสั่ง (ISA) ที่ดีที่สุดสำหรับงานนี้อาจไม่ใช่ RISC-V แต่เป็นบางอย่างเช่น EOF-EVM ด้วยเหตุผลดังต่อไปนี้:
โอปโค้ด ขนาดเล็ก ส่งผลให้ต้องเข้าถึงหน่วยความจำจำนวนมาก ซึ่งยากต่อการจัดการอย่างมีประสิทธิภาพด้วยวิธีการพิสูจน์ที่มีอยู่
เพื่อลดค่าใช้จ่ายในการแยกสาขา เอกสารล่าสุดของเราชื่อ Morgana แสดงให้เห็นวิธีการพิสูจน์โค้ดด้วย การกระโดดแบบคงที่ ( คล้ายกับ EOF ) ที่ประสิทธิภาพระดับพรีคอมไพเลอร์
ฉันแนะนำให้สร้างสถาปัตยกรรมใหม่ที่เป็นมิตรกับการพิสูจน์โดยมี MMU ขั้นต่ำที่อนุญาตให้รันสัญญาเป็นไฟล์ปฏิบัติการที่แยกจากกัน ฉันไม่คิดว่าควรเป็น RISC-V แต่ควรเป็น ISA ใหม่ที่ได้รับการปรับให้เหมาะสมสำหรับข้อจำกัดของโปรโตคอล SNARK หรือแม้แต่ ISA ที่สืบทอดชุดย่อยของ opcodes EVM บางส่วนก็อาจจะดีกว่า - อย่างที่เรารู้กันดีว่าการคอมไพล์ล่วงหน้าจะคงอยู่ต่อไปไม่ว่าเราจะชอบหรือไม่ก็ตาม ดังนั้น RISC-V จึงไม่นำการลดความซับซ้อนใดๆ มาสู่ที่นี่
