Vitalik: โซลูชันใหม่สำหรับปัญหาการปรับขยาย Ethereum L1
บทความนี้มาจาก: Vitalik ผู้ร่วมก่อตั้ง Ethereum
เรียบเรียงโดย | โอเดลี่แพลนเน็ตเดลี่ ( @OdailyChina )
นักแปล | อีธาน ( @ethanzhang_web3 )
นอกเหนือจากข้อกังวลเกี่ยวกับความปลอดภัยของเครือข่ายแล้ว คำวิพากษ์วิจารณ์ที่พบบ่อยที่สุดเกี่ยวกับการเพิ่มขีดจำกัดแก๊ส L1 ก็คือจะทำให้การรันโหนดแบบเต็มทำได้ยากยิ่งขึ้น โดยเฉพาะอย่างยิ่งในบริบทของแผนงานที่มุ่งเน้น ไปที่ การแยกโหนดเต็ม การจัดการกับปัญหานี้จำเป็นต้องเข้าใจบทบาทของโหนดเต็ม
ในอดีต ผู้คนคิดว่าโหนดเต็มทำหน้าที่ตรวจสอบข้อมูลบนเชน ดู ที่นี่ เพื่อดูมุมมองของฉันเองเกี่ยวกับสิ่งที่อาจเกิดขึ้นหากผู้ใช้ทั่วไปไม่สามารถยืนยันได้ หากนั่นเป็นปัญหาเดียว ZK-EVM จะปลดล็อกการปรับขนาด L1: ข้อจำกัดเดียวคือการรักษาต้นทุนการสร้างบล็อกและการพิสูจน์ให้ต่ำเพียงพอเพื่อให้ทั้งคู่ยังคงต้านทานการเซ็นเซอร์ 1 ใน n และสามารถแข่งขันในตลาดได้
แต่ที่จริงแล้วนี่ไม่ใช่ปัญหาเดียวเท่านั้น ปัญหาสำคัญอีกประการหนึ่งก็คือ การมีโหนดแบบเต็มนั้นมีค่ามาก เพราะคุณจะได้มีเซิร์ฟเวอร์ RPC ภายในเครื่องที่สามารถใช้อ่านเชนได้โดยไม่ต้องไว้วางใจ ทนต่อการเซ็นเซอร์ และเป็นมิตรต่อความเป็นส่วนตัว เอกสารนี้จะกล่าวถึงการปรับเปลี่ยนแผนงานการปรับขนาด L1 ปัจจุบันเพื่อบรรลุเป้าหมายนี้
เหตุใดจึงยังคงบรรลุความน่าเชื่อถือและความเป็นส่วนตัวผ่าน ZK-EVM + PIR
แผนงานความเป็นส่วนตัว ที่ฉันเผยแพร่เมื่อเดือนที่แล้วประกอบด้วย TEE + ORAM เป็นวิธีแก้ปัญหาในระยะสั้น และ PIR เป็นวิธีแก้ปัญหาในระยะยาว เมื่อรวมกับการตรวจสอบ Helios และ ZK-EVM แล้ว ผู้ใช้ทุกคนจะสามารถเชื่อมต่อกับ RPC ภายนอกพร้อมความมั่นใจเต็มเปี่ยมว่า: (i) เครือข่ายที่พวกเขาได้รับนั้นเป็นเครือข่ายที่ถูกต้อง และ (ii) ความเป็นส่วนตัวของข้อมูลของพวกเขาได้รับการรักษาไว้ ดังนั้น เราจึงอดไม่ได้ที่จะถามว่า ทำไมเราถึงหยุดอยู่แค่นี้ไม่ได้? โซลูชันการเข้ารหัสขั้นสูงเหล่านี้จะทำให้โหนดที่โฮสต์ด้วยตนเองกลายเป็นสิ่งล้าสมัยหรือไม่
ที่นี่ผมสามารถให้คำตอบได้สองสามข้อ:
โซลูชันการเข้ารหัสที่ไม่ต้องไว้วางใจอย่างสมบูรณ์ (เช่น PIR เซิร์ฟเวอร์ 1 ตัว) จะมีราคาแพงเกินไป ต้นทุนปัจจุบันสูงเกินกว่าจะปฏิบัติได้จริงและอาจยังคงมีราคาแพงแม้จะมีการปรับปรุงประสิทธิภาพหลายครั้งแล้วก็ตาม
ความเป็นส่วนตัวของข้อมูลเมตา ที่อยู่ IP ใดที่ส่งคำขอ เมื่อใด และรูปแบบของคำขอสามารถเปิดเผยข้อมูลได้มากเกี่ยวกับผู้ใช้
ความเสี่ยงจากการเซ็นเซอร์: โครงสร้างตลาดที่ถูกครอบงำโดยผู้ให้บริการ RPC จำนวนน้อยจะเผชิญกับแรงกดดันอย่างหนักในการปิดแพลตฟอร์มหรือเซ็นเซอร์ผู้ใช้ ผู้ให้บริการ RPC หลายรายไม่ได้ครอบคลุมถึงประเทศบางประเทศ
ด้วยเหตุผลเหล่านี้ จึงมีค่าที่จะทำให้แน่ใจว่าการรันโหนดส่วนบุคคลนั้นง่ายกว่าต่อไป
ลำดับความสำคัญในระยะสั้น
ให้ความสำคัญกับการเปิดตัว EIP-4444 อย่างเต็มรูปแบบจนถึงสถานะสุดท้ายซึ่งแต่ละโหนดจะจัดเก็บข้อมูลได้เพียง ~36 วันเท่านั้น วิธีนี้จะช่วยลดความต้องการพื้นที่ดิสก์ลงอย่างมาก ซึ่งเป็นปัญหาหลักที่ทำให้ผู้คนไม่สามารถรันโหนดได้มากขึ้น จากนั้นความต้องการพื้นที่ดิสก์ของโหนดจะเป็นดังนี้: (i) ขนาดสถานะ (ii) สาขา Merkle ของรัฐ และ (iii) ประวัติศาสตร์ 36 วัน
สร้างโซลูชันการจัดเก็บประวัติแบบกระจายซึ่งแต่ละโหนดสามารถจัดเก็บข้อมูลประวัติขนาดเล็กที่เก่ากว่ากำหนดเวลาได้ ใช้การลบรหัสเพื่อเพิ่มความทนทานสูงสุด สิ่งนี้ช่วยให้แน่ใจว่าบล็อคเชนไม่มีการเปลี่ยนแปลงโดยไม่ต้องพึ่งพาผู้ให้บริการแบบรวมศูนย์หรือสร้างภาระหนักให้กับผู้ดำเนินการโหนด
ปรับราคาก๊าซให้ราคาค่าจัดเก็บแพงขึ้น และค่าดำเนินการถูกกว่า สิ่งที่มีความสำคัญเร่งด่วนเป็นพิเศษคือการเพิ่มต้นทุนแก๊สในการสร้างสถานะใหม่: (i) SSTORE สำหรับช่องเก็บข้อมูลใหม่ (ii) การสร้างรหัสสัญญา (iii) การส่ง ETH ไปยังบัญชีที่ยังไม่มียอดคงเหลือหรือค่า nonce
ลำดับความสำคัญในระยะกลาง: การรับรองความถูกต้องแบบไร้รัฐ
เมื่อเราเปิดใช้งานการตรวจสอบแบบไม่มีสถานะแล้ว จะสามารถรันโหนดที่มีคุณสมบัติ RPC ได้ (นั่นคือ โหนดที่เก็บสถานะ) โดยไม่ต้องเก็บสาขาสถานะ Merkle วิธีนี้จะช่วยลดความต้องการพื้นที่จัดเก็บข้อมูลลงได้ประมาณ 2 เท่า
โหนดประเภทใหม่: โหนดที่ไม่มีสถานะบางส่วน
นี่เป็นแนวคิดใหม่และเป็นกุญแจสำคัญในการอนุญาตให้โหนดแต่ละโหนดทำงานได้เมื่อขีดจำกัดแก๊ส L1 เพิ่มขึ้น 10-100 เท่า
เราได้เพิ่มประเภทโหนดที่สามารถตรวจสอบบล็อกแบบไร้สถานะ ตรวจสอบทั้งเชน (ไม่ว่าจะผ่านการตรวจสอบแบบไร้สถานะหรือ ZK-EVM) และทำให้ส่วนต่างๆ ของสถานะอัปเดตอยู่เสมอ ตราบใดที่ข้อมูลที่ต้องการอยู่ภายในเซ็ตย่อยของสถานะนี้ โหนดจะสามารถตอบสนองคำขอ RPC ได้ คำขออื่น ๆ จะล้มเหลว (หรือต้องหันกลับไปใช้โซลูชันการเข้ารหัสโฮสต์ภายนอก ไม่ว่าจะดำเนินการดังกล่าวหรือไม่นั้นขึ้นอยู่กับผู้ใช้เลือกได้)
ส่วนที่แน่นอนของสถานะที่ถูกเก็บรักษาไว้ขึ้นอยู่กับการกำหนดค่าที่ผู้ใช้เลือก ต่อไปนี้คือตัวอย่างบางส่วน:
ทุกสถานะ ยกเว้นสัญญาขยะที่ทราบ
สถานะที่เกี่ยวข้องกับ EOA และ SCW ทั้งหมด รวมถึงโทเค็นและแอปพลิเคชัน ERC 20 และ ERC 721 ที่ใช้กันทั่วไปทั้งหมด
สถานะที่เชื่อมโยงกับ EOA และ SCW ทั้งหมดที่เข้าถึงในช่วงสองปีที่ผ่านมา และโทเค็น ERC 20 ที่ใช้กันทั่วไปบางส่วน รวมถึงชุดการแลกเปลี่ยนที่จำกัด แอปพลิเคชัน DeFi และความเป็นส่วนตัว
การกำหนดค่าสามารถจัดการได้ผ่านสัญญาแบบออนเชน: ผู้ใช้สามารถรันโหนดของตนด้วย --save_state_by_config 0x 12345...67890 ซึ่งจะระบุรายการที่อยู่ ช่องเก็บข้อมูล หรือพื้นที่กรองอื่น ๆ ในบางภาษาที่โหนดจะบันทึกและอัปเดตด้วยสถานะ หมายเหตุว่าผู้ใช้ไม่จำเป็นต้องบันทึกสาขา Merkle พวกเขาเพียงต้องบันทึกค่าเดิมเท่านั้น
โหนดประเภทนี้ช่วยให้ผู้ใช้สามารถเข้าถึงสถานะที่สนใจได้โดยตรงภายในเครื่องและเพิ่มความเป็นส่วนตัวในการเข้าถึงสถานะนั้นให้สูงสุด
