วันนี้ แนวคิดใหม่ถือกำเนิดขึ้นอย่างเงียบๆ ในฟอรัมการวิจัย Ethereum: Proof of Validator
กลไกโปรโตคอลนี้ช่วยให้โหนดเครือข่ายสามารถพิสูจน์ได้ว่าพวกเขาเป็นผู้ตรวจสอบความถูกต้องของ Ethereum โดยไม่ต้องเปิดเผยตัวตนเฉพาะของพวกเขา
สิ่งนี้เกี่ยวอะไรกับเรา?
ภายใต้สถานการณ์ปกติ ตลาดมีแนวโน้มที่จะให้ความสนใจกับเรื่องราวผิวเผินที่เกิดจากนวัตกรรมทางเทคโนโลยีบางอย่างบน Ethereum และแทบจะไม่ได้ค้นคว้าเทคโนโลยีในเชิงลึกล่วงหน้าเลย ตัวอย่างเช่น การอัพเกรดในเซี่ยงไฮ้ การควบรวมกิจการ การโอนจาก PoW ไปยัง PoS และการขยาย Ethereum ตลาดจะจดจำเฉพาะเรื่องราวของ LSD, LSDFi และการให้คำมั่นใหม่เท่านั้น
แต่อย่าลืมว่าประสิทธิภาพและความปลอดภัยเป็นสิ่งสำคัญที่สุดสำหรับ Ethereum แบบแรกกำหนดขีดจำกัดบน ในขณะที่แบบหลังกำหนดบรรทัดล่างสุด
จะเห็นได้อย่างชัดเจนว่าในอีกด้านหนึ่ง Ethereum ได้ส่งเสริมโซลูชั่นการขยายที่หลากหลายเพื่อปรับปรุงประสิทธิภาพ แต่ในทางกลับกัน บนเส้นทางสู่การขยายตัว นอกเหนือจากการฝึกฝนทักษะภายในแล้ว ยังจำเป็นต้องป้องกันจากภายนอกอีกด้วย การโจมตี
ตัวอย่างเช่น หากโหนดการตรวจสอบถูกโจมตีและข้อมูลไม่พร้อมใช้งาน การเล่าเรื่องและแผนการขยายทั้งหมดตามตรรกะการจำนำ Ethereum อาจได้รับผลกระทบจากเนื้อหาทั้งหมด เพียงแต่ผลกระทบและความเสี่ยงถูกซ่อนอยู่เบื้องหลัง ผู้ใช้ปลายทางและนักเก็งกำไรนั้นตรวจจับได้ยาก และบางครั้งพวกเขาก็ไม่สนใจด้วยซ้ำ
Proof of Validator ที่จะกล่าวถึงในบทความนี้อาจเป็นปริศนาด้านความปลอดภัยที่สำคัญในการขยาย Ethereum
เนื่องจากการขยายกำลังการผลิตมีความจำเป็น วิธีการลดความเสี่ยงที่อาจเกิดขึ้นที่เกี่ยวข้องกับกระบวนการขยายกำลังการผลิตจึงเป็นปัญหาด้านความปลอดภัยที่หลีกเลี่ยงไม่ได้ และยังเกี่ยวข้องอย่างใกล้ชิดกับเราทุกคนในแวดวงอีกด้วย
ดังนั้นจึงจำเป็นต้องชี้แจงภาพรวมของ Proof of Validator ที่เสนอใหม่ทั้งหมด อย่างไรก็ตาม เนื่องจากข้อความฉบับเต็มในฟอรัมทางเทคนิคนั้นกระจัดกระจายและฮาร์ดคอร์เกินไป และเกี่ยวข้องกับแผนงานและแนวคิดการขยายจำนวนมาก สถาบันวิจัย Shenchao จึงรวมโพสต์ต้นฉบับและจัดเรียงข้อมูลที่เกี่ยวข้องที่จำเป็น และดำเนินการวิเคราะห์ความเป็นมา ความจำเป็น และผลกระทบที่อาจเกิดขึ้นจาก Proof of Validator เรียนรู้เกี่ยวกับการอ่าน
การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล: ความก้าวหน้าครั้งสำคัญในการขยายความจุ
ไม่ต้องกังวล ก่อนที่จะเปิดตัว Proof of Validator อย่างเป็นทางการ จำเป็นต้องเข้าใจตรรกะของการขยายตัวของ Ethereum ในปัจจุบันและความเสี่ยงที่อาจเกิดขึ้นที่เกี่ยวข้อง
ชุมชน Ethereum กำลังส่งเสริมแผนการขยายหลายอย่างอย่างแข็งขัน หนึ่งในนั้นคือ Data Availability Sampling (เรียกสั้นๆ ว่า DAS) ถือเป็นเทคโนโลยีที่สำคัญที่สุด
หลักการคือการแบ่งข้อมูลบล็อกทั้งหมดออกเป็น "ตัวอย่าง" หลาย ๆ โหนดในเครือข่ายจำเป็นต้องได้รับตัวอย่างสองสามตัวอย่างที่เกี่ยวข้องกับตัวเองเพื่อตรวจสอบบล็อกทั้งหมด
ซึ่งจะช่วยลดปริมาณพื้นที่จัดเก็บและการคำนวณต่อโหนดได้อย่างมาก สำหรับตัวอย่างที่เข้าใจง่ายก็คล้ายกับการสำรวจตัวอย่างของเรา โดยการสัมภาษณ์บุคคลต่างๆ เราสามารถสรุปสถานการณ์โดยรวมของประชากรทั้งหมดได้
ซึ่งจะช่วยลดปริมาณพื้นที่จัดเก็บและการคำนวณต่อโหนดได้อย่างมาก สำหรับตัวอย่างที่เข้าใจง่ายก็คล้ายกับการสำรวจตัวอย่างของเรา โดยการสัมภาษณ์บุคคลต่างๆ เราสามารถสรุปสถานการณ์โดยรวมของประชากรทั้งหมดได้
โดยเฉพาะอย่างยิ่ง การดำเนินการตาม DAS มีการอธิบายโดยย่อดังนี้:
- ผู้ผลิตบล็อกแบ่งข้อมูลบล็อกออกเป็นหลายตัวอย่าง
- โหนดเครือข่ายแต่ละโหนดจะได้รับตัวอย่างความสนใจเพียงไม่กี่ตัวอย่างเท่านั้น ไม่ใช่ข้อมูลบล็อกทั้งหมด
- โหนดเครือข่ายสามารถสุ่มตัวอย่างและตรวจสอบว่าข้อมูลบล็อกทั้งหมดมีอยู่หรือไม่โดยการรับตัวอย่างที่แตกต่างกัน
ด้วยการสุ่มตัวอย่างนี้ แม้ว่าแต่ละโหนดจะประมวลผลข้อมูลจำนวนเล็กน้อยเท่านั้น แต่ก็สามารถตรวจสอบความพร้อมใช้งานของข้อมูลของบล็อกเชนทั้งหมดได้อย่างเต็มที่ สิ่งนี้สามารถเพิ่มขนาดบล็อกได้มากและบรรลุการขยายตัวอย่างรวดเร็ว
อย่างไรก็ตาม รูปแบบการสุ่มตัวอย่างนี้มีปัญหาสำคัญ: ตัวอย่างจำนวนมากถูกเก็บไว้ที่ไหน ซึ่งต้องใช้เครือข่ายแบบกระจายอำนาจทั้งชุดเพื่อรองรับ
ตารางแฮชแบบกระจาย: บ้านของตัวอย่าง
สิ่งนี้ทำให้ Distributed Hash Table (DHT) มีโอกาสที่จะแสดงความสามารถของตน
DHT ถือได้ว่าเป็นฐานข้อมูลแบบกระจายขนาดใหญ่ ซึ่งใช้ฟังก์ชันแฮชเพื่อจับคู่ข้อมูลลงในพื้นที่ที่อยู่ และโหนดที่แตกต่างกันมีหน้าที่ในการเข้าถึงข้อมูลในส่วนที่อยู่ที่แตกต่างกัน สามารถใช้เพื่อค้นหาและจัดเก็บตัวอย่างในโหนดขนาดใหญ่ได้อย่างรวดเร็ว
โดยเฉพาะอย่างยิ่ง หลังจากที่ DAS แบ่งข้อมูลบล็อกออกเป็นหลายตัวอย่างแล้ว ตัวอย่างเหล่านี้จำเป็นต้องกระจายไปยังโหนดต่างๆ ในเครือข่ายเพื่อจัดเก็บข้อมูล DHT สามารถจัดเตรียมวิธีการแบบกระจายอำนาจเพื่อจัดเก็บและเรียกค้นตัวอย่างเหล่านี้ แนวคิดพื้นฐานคือ:
- การใช้ฟังก์ชันแฮชที่สอดคล้องกัน ตัวอย่างจะถูกแมปลงในพื้นที่ที่อยู่ขนาดใหญ่
- แต่ละโหนดในเครือข่ายมีหน้าที่จัดเก็บและจัดเตรียมตัวอย่างข้อมูลภายในช่วงที่อยู่
- เมื่อจำเป็นต้องใช้ตัวอย่างบางตัวอย่าง ที่อยู่ที่เกี่ยวข้องสามารถพบได้ผ่านแฮช และโหนดที่รับผิดชอบช่วงที่อยู่สามารถพบได้ในเครือข่ายเพื่อรับตัวอย่าง
ตัวอย่างเช่น ตามกฎบางประการ แต่ละตัวอย่างสามารถแฮชไปยังที่อยู่ได้ โหนด A รับผิดชอบที่อยู่ 0-1,000 และโหนด B รับผิดชอบที่อยู่ 1001-2000
จากนั้นตัวอย่างที่มีที่อยู่ 599 จะถูกจัดเก็บไว้ในโหนด A เมื่อต้องการตัวอย่างนี้ ให้ค้นหาที่อยู่ 599 ผ่านแฮชเดียวกัน จากนั้นค้นหาโหนด A ที่รับผิดชอบที่อยู่ในเครือข่าย และรับตัวอย่างจากโหนดนั้น
วิธีการนี้ทลายข้อจำกัดของการจัดเก็บข้อมูลแบบรวมศูนย์ และปรับปรุงความทนทานต่อข้อผิดพลาดและความสามารถในการปรับขนาดได้อย่างมาก นี่เป็นโครงสร้างพื้นฐานเครือข่ายที่จำเป็นสำหรับพื้นที่จัดเก็บตัวอย่าง DAS
เมื่อเปรียบเทียบกับการจัดเก็บและการเรียกข้อมูลแบบรวมศูนย์ DHT สามารถปรับปรุงความทนทานต่อข้อผิดพลาด หลีกเลี่ยงความล้มเหลวจุดเดียว และเพิ่มความสามารถในการปรับขนาดเครือข่าย นอกจากนี้ DHT ยังสามารถช่วยป้องกันการโจมตี เช่น "การซ่อนตัวอย่าง" ที่กล่าวถึงใน DAS
เมื่อเปรียบเทียบกับการจัดเก็บและการเรียกข้อมูลแบบรวมศูนย์ DHT สามารถปรับปรุงความทนทานต่อข้อผิดพลาด หลีกเลี่ยงความล้มเหลวจุดเดียว และเพิ่มความสามารถในการปรับขนาดเครือข่าย นอกจากนี้ DHT ยังสามารถช่วยป้องกันการโจมตี เช่น "การซ่อนตัวอย่าง" ที่กล่าวถึงใน DAS
จุดปวดของ DHT: การโจมตีของซีบิล
อย่างไรก็ตาม DHT ยังมีส้นเท้าของ Achilles ซึ่งเป็นภัยคุกคามจากการโจมตีของซีบิล ผู้โจมตีสามารถสร้างโหนดปลอมจำนวนมากในเครือข่าย และโหนดจริงที่อยู่รอบๆ จะถูก "ล้นหลาม" โดยโหนดปลอมเหล่านี้
ในการเปรียบเทียบ พ่อค้าหาบเร่ที่ซื่อสัตย์รายล้อมไปด้วยสินค้าลอกเลียนแบบเรียงรายเป็นแถวๆ และเป็นเรื่องยากสำหรับผู้ใช้ที่จะหาผลิตภัณฑ์ของแท้ ด้วยวิธีนี้ ผู้โจมตีสามารถควบคุมเครือข่าย DHT และทำให้ตัวอย่างไม่พร้อมใช้งาน
ตัวอย่างเช่น หากต้องการรับตัวอย่างตามที่อยู่ 1,000 จำเป็นต้องค้นหาโหนดที่รับผิดชอบที่อยู่นี้ อย่างไรก็ตาม หลังจากถูกล้อมรอบด้วยโหนดปลอมนับหมื่นที่สร้างขึ้นโดยผู้โจมตี คำขอจะถูกส่งไปยังโหนดปลอมอย่างต่อเนื่อง และไม่สามารถเข้าถึงโหนดที่รับผิดชอบที่อยู่จริงได้ ผลลัพธ์คือไม่สามารถรับตัวอย่างได้ และทั้งการจัดเก็บและการตรวจสอบล้มเหลว
เพื่อแก้ไขปัญหานี้ จำเป็นต้องสร้างเลเยอร์เครือข่ายที่มีความน่าเชื่อถือสูงบน DHT ซึ่งเข้าร่วมโดยโหนดตัวตรวจสอบเท่านั้น แต่เครือข่าย DHT เองไม่สามารถระบุได้ว่าโหนดเป็นตัวตรวจสอบหรือไม่
สิ่งนี้ขัดขวางการขยายตัวของ DAS และ Ethereum อย่างจริงจัง มีวิธีใดบ้างที่จะต่อต้านภัยคุกคามนี้และรับประกันความน่าเชื่อถือของเครือข่าย?
Proof of Validator: โซลูชัน ZK เพื่อปกป้องความปลอดภัยของการขยาย
ตอนนี้ กลับไปที่ประเด็นหลักของบทความนี้: Proof of Validator
ในฟอรัมเทคโนโลยี Ethereum George Kadianakis, Mary Maller, Andrija Novakovic และ Suphanat Chunhapanya ร่วมกันเสนอข้อเสนอนี้ในวันนี้
แนวคิดทั่วไปคือหากเราสามารถหาวิธีที่จะอนุญาตให้เฉพาะผู้ตรวจสอบที่ซื่อสัตย์เข้าร่วม DHT ในแผนการขยาย DHT ในส่วนก่อนหน้าได้ ผู้ที่เป็นอันตรายที่ต้องการเริ่มการโจมตี Sybil จะต้องให้คำมั่นสัญญา ETH จำนวนมากด้วย . เพิ่มค่าใช้จ่ายในการทำชั่วในเชิงเศรษฐกิจเพิ่มขึ้นอย่างมาก
กล่าวอีกนัยหนึ่ง แนวคิดนี้คุ้นเคยกับเรามากกว่า: ฉันอยากรู้ว่าคุณเป็นคนดีและสามารถระบุคนไม่ดีได้โดยไม่ต้องรู้ตัวตนของคุณ
ในสถานการณ์การพิสูจน์ประเภทนี้ซึ่งมีข้อมูลที่จำกัด การพิสูจน์ความรู้เป็นศูนย์อาจมีประโยชน์อย่างเห็นได้ชัด
ดังนั้น Proof of Validator (ต่อไปนี้จะเรียกว่า PoV) สามารถใช้เพื่อสร้างเครือข่าย DHT ที่น่าเชื่อถือสูง ซึ่งประกอบด้วยโหนดการตรวจสอบที่ซื่อสัตย์เท่านั้น ซึ่งต้านทานการโจมตีของ Sybil ได้อย่างมีประสิทธิภาพ
แนวคิดพื้นฐานคือการให้แต่ละโหนดการตรวจสอบลงทะเบียนคีย์สาธารณะบนบล็อกเชน จากนั้นใช้เทคโนโลยีพิสูจน์ความรู้เป็นศูนย์เพื่อพิสูจน์ว่ารู้คีย์ส่วนตัวที่สอดคล้องกับคีย์สาธารณะ ซึ่งเทียบเท่ากับการนำใบรับรองประจำตัวของคุณเองออกมาเพื่อพิสูจน์ว่าคุณเป็นโหนดการตรวจสอบ
นอกจากนี้ PoV ยังได้รับการออกแบบมาเพื่อซ่อนข้อมูลประจำตัวของผู้ตรวจสอบบนเลเยอร์เครือข่ายจากการโจมตี DoS (Denial of Service) บนโหนดที่ตรวจสอบความถูกต้อง นั่นคือโปรโตคอลไม่ได้คาดหวังว่าผู้โจมตีจะสามารถบอกได้ว่าโหนด DHT ใดที่สอดคล้องกับตัวตรวจสอบความถูกต้องตัวใด
นอกจากนี้ PoV ยังได้รับการออกแบบมาเพื่อซ่อนข้อมูลประจำตัวของผู้ตรวจสอบบนเลเยอร์เครือข่ายจากการโจมตี DoS (Denial of Service) ในการตรวจสอบโหนด นั่นคือโปรโตคอลไม่ได้คาดหวังว่าผู้โจมตีจะสามารถบอกได้ว่าโหนด DHT ใดที่สอดคล้องกับตัวตรวจสอบความถูกต้องตัวใด
แล้วจะทำยังไงล่ะ? โพสต์ต้นฉบับใช้สูตรทางคณิตศาสตร์และการอนุมานจำนวนมาก ดังนั้น ฉันจะไม่ลงรายละเอียดที่นี่ เราให้เวอร์ชันที่เรียบง่าย:
ในแง่ของการใช้งานเฉพาะ จะใช้ Merkle tree หรือ Lookup table ตัวอย่างเช่น ใช้แผนผัง Merkle เพื่อพิสูจน์ว่าคีย์สาธารณะการลงทะเบียนมีอยู่ในแผนผัง Merkle ของรายการคีย์สาธารณะ จากนั้นพิสูจน์ว่าคีย์สาธารณะการสื่อสารเครือข่ายที่ได้รับจากคีย์สาธารณะนี้ตรงกัน กระบวนการทั้งหมดเกิดขึ้นได้ด้วยการพิสูจน์ความรู้เป็นศูนย์ และตัวตนที่แท้จริงจะไม่ถูกเปิดเผย
หากข้ามรายละเอียดทางเทคนิคเหล่านี้ไป ผลลัพธ์สุดท้ายของ PoV คือ:
เฉพาะโหนดที่ผ่านการยืนยันตัวตนเท่านั้นที่สามารถเข้าร่วมเครือข่าย DHT ได้ และความปลอดภัยก็เพิ่มขึ้นอย่างมาก ซึ่งสามารถต้านทานการโจมตีของ Sybil ได้อย่างมีประสิทธิภาพ และป้องกันไม่ให้ตัวอย่างถูกซ่อนหรือแก้ไขโดยเจตนา PoV มอบเครือข่ายพื้นฐานที่เชื่อถือได้สำหรับ DAS ซึ่งช่วยให้ Ethereum ขยายตัวอย่างรวดเร็วทางอ้อม
อย่างไรก็ตาม PoV ปัจจุบันยังอยู่ในขั้นตอนการวิจัยเชิงทฤษฎี และยังมีความไม่แน่นอนว่าจะสามารถนำไปใช้ได้หรือไม่
อย่างไรก็ตาม นักวิจัยหลายคนในโพสต์นี้ได้ทำการทดลองในระดับเล็กๆ และผลลัพธ์แสดงให้เห็นว่าประสิทธิภาพของ PoV ในการเสนอการพิสูจน์ ZK และประสิทธิภาพของผู้ตรวจสอบในการรับการพิสูจน์นั้นไม่ได้แย่เลย เป็นที่น่าสังเกตว่าอุปกรณ์ทดลองของพวกเขาเป็นเพียงโน้ตบุ๊กซึ่งติดตั้งโปรเซสเซอร์ Intel i7 เมื่อ 5 ปีที่แล้วเท่านั้น
สุดท้าย PoV ปัจจุบันยังอยู่ในขั้นตอนการวิจัยเชิงทฤษฎี และยังมีความไม่แน่นอนว่าจะสามารถนำไปใช้ได้หรือไม่ ไม่ว่าจะแสดงถึงก้าวสำคัญสู่ความสามารถในการปรับขนาดที่มากขึ้นสำหรับบล็อกเชนก็ตาม เนื่องจากเป็นองค์ประกอบสำคัญในแผนงานการขยาย Ethereum จึงสมควรได้รับความสนใจอย่างต่อเนื่องจากทั้งอุตสาหกรรม
ความคิดเห็นทั้งหมด