Proof of Validator: รูปแบบข้อมูลรับรองที่ไม่ระบุชื่ออย่างง่ายสำหรับ DHT ของ Ethereum

แนะนำสกุลเงิน

แผนงานของ Ethereum ใช้เทคโนโลยีการปรับขนาดที่เรียกว่า Data Availability Sampling (DAS) 6 DAS แนะนำ<a href="https://notes.ethereum.org/ @djrtwo /das-requirements">ข้อกำหนดใหม่ 4 ถึงสแต็กเครือข่ายของ Ethereum ซึ่งจำเป็นต้องมีการใช้ โปรโตคอลเครือข่ายพิเศษ 7 <a href="https://notes.ethereum.org/@dankrad /S-Kademlia-DAS"> โปรโตคอลที่โดดเด่นหนึ่งรายการ ข้อเสนอที่ 4 ใช้ Distributed Hash Table (DHT) ที่ใช้ Kademlia 2 เพื่อจัดเก็บและเรียกค้นตัวอย่างข้อมูล

อย่างไรก็ตาม DHTs 4 ไวต่อการโจมตีของ Sybil: ผู้โจมตีที่ควบคุมโหนด DHT จำนวนมากสามารถทำให้ตัวอย่าง DAS ไม่พร้อมใช้งาน เพื่อรับมือกับภัยคุกคามนี้ สามารถสร้างเลเยอร์เครือข่ายที่มีความน่าเชื่อถือสูงได้ ซึ่งประกอบด้วยตัวตรวจสอบความถูกต้องของบีคอนเชนเท่านั้น มาตรการรักษาความปลอดภัยดังกล่าวเพิ่มอุปสรรคให้กับผู้โจมตีอย่างมาก เนื่องจากตอนนี้พวกเขาต้องเดิมพัน ETH ของตนเองเพื่อโจมตี DHT

ในโพสต์นี้ เราขอแนะนำ Proof of Validator Protocol ซึ่งช่วยให้ผู้เข้าร่วม DHT สามารถแสดงให้เห็นโดยปราศจากความรู้ว่าพวกเขาคือ Ethereum Validator

แรงจูงใจ: การโจมตี "การซ่อนตัวอย่าง" บน DAS

ในส่วนนี้ เรากระตุ้นให้มีการพิสูจน์โปรโตคอลผู้ตรวจสอบความถูกต้องเพิ่มเติมโดยการอธิบายการโจมตีของ Sybil ต่อการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล

โปรโตคอล DAS หมุนรอบตัวสร้างบล็อกเพื่อให้แน่ใจว่าข้อมูลบล็อกจะพร้อมใช้งานเพื่อให้ไคลเอนต์สามารถดึงข้อมูลได้ แนวทางปัจจุบันเกี่ยวข้องกับการแบ่งพาร์ติชันข้อมูลออกเป็นกลุ่มตัวอย่าง และผู้เข้าร่วมเครือข่ายจะดึงเฉพาะตัวอย่างที่เกี่ยวข้องกับความสนใจของตนเท่านั้น

)

พิจารณาสถานการณ์ที่ผู้โจมตี Sybil ต้องการป้องกันไม่ให้ผู้เข้าร่วมเครือข่ายดึงตัวอย่างจากโหนดของเหยื่อ ซึ่งมีหน้าที่จัดหาตัวอย่าง ตามที่อธิบายไว้ในภาพด้านบน ผู้โจมตีจะสร้าง ID โหนดจำนวนมากซึ่งใกล้เคียงกับ ID โหนดของเหยื่อ ด้วยการล้อมรอบโหนดของเหยื่อด้วยโหนดของตนเอง ผู้โจมตีจะขัดขวางไม่ให้ไคลเอ็นต์ค้นพบโหนดของเหยื่อ เนื่องจากโหนดชั่วร้ายจะจงใจระงับข้อมูลเกี่ยวกับการมีอยู่ของเหยื่อ

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการโจมตีของ Sybil โปรดดู รายงานการวิจัยล่าสุด 2 เกี่ยวกับการโจมตี DHT Eclipse นอกจากนี้<a href="https://notes.ethereum.org/ @dankrad /S-Kademlia-DAS#SKademlia-modifications">Dankrad's ข้อเสนอโปรโตคอลเครือข่าย DAS 8 อธิบายว่าโปรโตคอล S/Kademlia DHT ได้รับผลกระทบจากการโจมตีดังกล่าวอย่างไร และแสดงให้เห็นถึงความจำเป็นในการพิสูจน์โปรโตคอลตรวจสอบความถูกต้อง

หลักฐานการตรวจสอบ

การโจมตีข้างต้นกระตุ้นให้เกิดความจำเป็นในการพิสูจน์โปรโตคอล validator: หากมีเพียงผู้ตรวจสอบความถูกต้องเท่านั้นที่สามารถเข้าร่วม DHT ได้ ผู้โจมตีที่ต้องการเริ่มการโจมตี Sybil จะต้องเดิมพัน ETH จำนวนมากด้วย

การใช้โปรโตคอล Proof of Validator ของเรา ช่วยให้มั่นใจได้ว่ามีเพียงผู้ตรวจสอบ Beacon Chain เท่านั้นที่สามารถเข้าร่วม DHT และผู้ตรวจสอบแต่ละรายจะได้รับข้อมูลระบุตัวตน DHT ที่ไม่ซ้ำกัน

นอกจากนี้ สำหรับความยืดหยุ่นของเครื่องมือตรวจสอบความถูกต้องของ DoS เรายังมุ่งหวังที่จะซ่อนข้อมูลประจำตัวของผู้ตรวจสอบบนเลเยอร์เครือข่ายด้วย นั่นคือเราไม่ต้องการให้ผู้โจมตีสามารถบอกได้ว่าโหนด DHT ใดที่สอดคล้องกับตัวตรวจสอบความถูกต้องตัวใด

เพื่อให้บรรลุวัตถุประสงค์เหล่านี้ โปรโตคอล Proof of Validator จะต้องเป็นไปตามข้อกำหนดต่อไปนี้:

• ความเป็นเอกลักษณ์: เครื่องมือตรวจสอบบีคอนเชนแต่ละตัวจะต้องสามารถได้รับคู่คีย์ที่ไม่ซ้ำกันเพียงคู่เดียว คุณสมบัตินี้ไม่เพียงจำกัดจำนวนโหนดที่ผู้โจมตี Sybil สามารถสร้างได้ แต่ยังช่วยให้ผู้เข้าร่วมเครือข่ายสามารถลงโทษโหนดที่ทำงานผิดปกติในพื้นที่ได้โดยการบล็อกรายการคู่คีย์ที่ได้รับ
• ความเป็นส่วนตัว: ฝ่ายตรงข้ามจะต้องไม่สามารถเรียนรู้ได้ว่าเครื่องมือตรวจสอบใดที่สอดคล้องกับคีย์สาธารณะที่ได้รับมาโดยเฉพาะ
• เวลาในการตรวจสอบ: กระบวนการตรวจสอบของโปรโตคอลจะต้องมีประสิทธิภาพ โดยใช้เวลาน้อยกว่า 200 มิลลิวินาทีต่อโหนด ทำให้แต่ละโหนดสามารถเรียนรู้โหนดใหม่อย่างน้อยห้าโหนดต่อวินาที

Bob จะใช้โปรโตคอลพิสูจน์การตรวจสอบความถูกต้องดังกล่าวในระหว่างการสร้างการเชื่อมต่อในเลเยอร์ DHT เพื่อให้อลิซรู้ว่าเธอกำลังพูดคุยกับเครื่องมือตรวจสอบความถูกต้อง

หลักฐานการตรวจสอบโปรโตคอล

โปรโตคอล Proof of Validator ของเรานั้นเป็นแผนข้อมูลประจำตัวที่ไม่เปิดเผยตัวตนอย่างมีประสิทธิภาพ วัตถุประสงค์คือเพื่อให้อลิซสามารถสร้างคีย์ที่ได้รับเฉพาะซึ่งแสดงเป็น D หากเธอเป็นผู้ตรวจสอบความถูกต้อง ต่อมา อลิซใช้คีย์ที่ได้รับ D นี้ภายในเลเยอร์เครือข่าย

ในการออกแบบโปรโตคอลนี้ วัตถุประสงค์ของเราคือการสร้างโซลูชันที่ทั้งนำไปใช้และวิเคราะห์ได้อย่างตรงไปตรงมา เพื่อให้แน่ใจว่าจะตรงตามข้อกำหนดที่ระบุไว้ในวิธีที่มีประสิทธิภาพ

ภาพรวมโปรโตคอล

โปรโตคอลใช้โปรโตคอลย่อยที่พิสูจน์ความเป็นสมาชิก โดยที่อลิซพิสูจน์ว่าเธอเป็นผู้ตรวจสอบความถูกต้องด้วยการสาธิตความรู้เกี่ยวกับพรีอิมเมจแฮชที่เป็นความลับโดยใช้การพิสูจน์ ZK จากนั้นอลิซจึงสร้างคู่คีย์ที่ไม่ซ้ำใครซึ่งได้มาจากพรีอิมเมจแฮชลับนั้น

โปรโตคอลย่อยการพิสูจน์ความเป็นสมาชิกสามารถสร้างอินสแตนซ์ได้ด้วยวิธีต่างๆ ในโพสต์นี้ เราจะแสดงโปรโตคอลโดยใช้แผนผัง Merkle และโปรโตคอลที่สองโดยใช้การค้นหา

แม้ว่าทั้งสองแนวทางจะแสดงให้เห็นถึงประสิทธิภาพที่ยอมรับได้ แต่ก็มีข้อดีข้อเสียที่แตกต่างกัน ต้นไม้ Merkle อาศัยฟังก์ชันแฮชที่เป็นมิตรกับ SNARK เช่น Poseidon (ซึ่งอาจถือเป็นการทดลอง) ในทางกลับกัน โปรโตคอลการค้นหาที่มีประสิทธิภาพขึ้นอยู่กับการตั้งค่าขนาดที่เชื่อถือได้ของ powers-of-tau ซึ่งเท่ากับขนาดของชุดเครื่องมือตรวจสอบ (ปัจจุบันมีเครื่องมือตรวจสอบความถูกต้อง 700,000 ตัว แต่กำลังเพิ่มขึ้น)

ตอนนี้เรามาดูโปรโตคอลกันดีกว่า:

แนวทางที่ 1: ต้นไม้ Merkle

ต้นไม้ Merkle มีการใช้อย่างแพร่หลายในการพิสูจน์การเป็นสมาชิก (เช่น ดู เซมาฟอร์ 3) ต่อไปนี้คือข้อดีข้อเสียเมื่อออกแบบหลักฐานการเป็นสมาชิกโดยใช้แผนผัง Merkle:

• แง่บวก: ไม่จำเป็นต้องตั้งค่าที่เชื่อถือได้
• แง่บวก: ง่ายต่อการเข้าใจ
• เชิงลบ: อาศัยฟังก์ชันแฮชที่เป็นมิตรกับ SNARK เช่น Poseidon
• เชิงลบ: การสร้างหลักฐานช้าลง

ด้านล่างเราจะอธิบายโปรโตคอลการพิสูจน์การตรวจสอบความถูกต้องโดยอิงจากแผนผัง Merkle:

โปรโตคอล Proof-of-validator โดยใช้ Merkle tree

)

ในตอนท้ายของโปรโตคอล Alice สามารถใช้ D ใน DHT เพื่อลงนามข้อความและรับข้อมูลระบุตัวตนของโหนด DHT ที่เป็นเอกลักษณ์ของเธอ

ตอนนี้เรามาดูโซลูชันที่ซับซ้อนกว่าเล็กน้อย แต่มีประสิทธิภาพมากกว่าโดยใช้การค้นหา

แนวทางที่ 2: การค้นหา

นี่คือพื้นที่การแลกเปลี่ยนของการใช้โปรโตคอล การค้นหา 2 เช่น Caulk 2:

• แง่บวก: การสร้างข้อพิสูจน์ที่มีประสิทธิภาพอย่างยิ่ง (ใช้ขั้นตอนก่อนการประมวลผล)
• แง่บวก: สามารถปรับโปรโตคอลเพื่อใช้ฟังก์ชันแฮชปกติแทนโพไซดอนได้
• เชิงลบ: ต้องมีการตั้งค่าขนาดใหญ่ที่เชื่อถือได้ (ควรเท่ากับขนาดของเครื่องมือตรวจสอบความถูกต้อง)

ด้านล่างนี้เราจะอธิบายหลักฐานที่ชัดเจนของโปรโตคอลผู้ตรวจสอบความถูกต้อง:

หลักฐานการตรวจสอบโปรโตคอลโดยใช้การค้นหา

เช่นเดียวกับแนวทางของ Merkle ทุกประการ เครื่องมือตรวจสอบความถูกต้องทุกตัวที่ฉันลงทะเบียนค่า pi ใหม่บนบล็อกเชนนั้น:

ประสิทธิภาพ

เราเปรียบเทียบรันไทม์ของโปรโตคอลพิสูจน์ความเป็นสมาชิกของเรา (ลิงก์ 6 ไปยัง โค้ดวัดประสิทธิภาพ 5) ในแง่ของการสร้างและการตรวจสอบหลักฐาน โปรดทราบว่าแม้ว่าหลักฐานการเป็นสมาชิกเป็นเพียงส่วนหนึ่งของโปรโตคอลหลักฐานการตรวจสอบความถูกต้องของเรา แต่เราคาดว่าหลักฐานดังกล่าวจะมีอิทธิพลเหนือเวลาดำเนินการโดยรวม

ด้านล่างนี้ เราได้จัดเตรียมผลลัพธ์เกณฑ์มาตรฐานสำหรับการพิสูจน์ความเป็นสมาชิกของ Merkle Tree โดยใช้ระบบพิสูจน์ Halo2 โดยมี IPA เป็นรูปแบบข้อผูกมัดพหุนาม IPA เป็นโครงการที่ช้ากว่า KZG แต่ไม่ต้องการการตั้งค่าที่เชื่อถือได้เพื่อเพิ่มข้อได้เปรียบของแนวทาง Merkle Tree ให้สูงสุด

เราสังเกตว่าทั้งเวลาของผู้พิสูจน์และผู้ตรวจสอบสอดคล้องกับข้อกำหนดด้านประสิทธิภาพของเราเป็นอย่างดี ด้วยเหตุผลนี้ เราจึงตัดสินใจเทียบกับการเปรียบเทียบแนวทางที่ใช้ Caulk เนื่องจากประสิทธิภาพของมันคาดว่าจะดีขึ้นอย่างมากในทุกประเภท (โดยเฉพาะเวลาพิสูจน์และขนาดการพิสูจน์)

เกณฑ์มาตรฐานถูกรวบรวมบนแล็ปท็อปที่ใช้ Intel i7-8550U (CPU อายุห้าปี)

อภิปราย

ตัวตนที่หมุนเวียน

คุณสมบัติที่เป็นเอกลักษณ์ของโปรโตคอล Proof of Validator ช่วยให้มั่นใจได้ว่าผู้เข้าร่วมเครือข่ายแต่ละรายมีคู่คีย์ที่ได้รับที่แตกต่างกัน อย่างไรก็ตาม สำหรับโปรโตคอลเครือข่ายบางโปรโตคอล อาจเป็นประโยชน์ที่จะอนุญาตให้ผู้ตรวจสอบความถูกต้องหมุนเวียนข้อมูลระบุตัวตน โดยที่คีย์ที่ได้รับจะเปลี่ยนเป็นระยะๆ หรืออาจเป็นรายวัน

ในสถานการณ์เช่นนี้ หากอีฟประพฤติตัวไม่เหมาะสมในวันใดวันหนึ่ง อลิซก็สามารถบล็อกเธอในวันนั้นได้ อย่างไรก็ตาม ในวันถัดไป อีฟสามารถสร้างคีย์ที่ได้รับใหม่ซึ่งไม่อยู่ในรายการบล็อก หากเราต้องการสามารถบล็อกผู้ตรวจสอบความถูกต้องในรายการบล็อกอย่างถาวรโดยอิงตามข้อมูลประจำตัวที่หมุนเวียน เราจะต้องใช้แผนข้อมูลรับรองที่ไม่เปิดเผยตัวตนขั้นสูงกว่า เช่น SNARKBlock 1

ทำไมไม่ใช้รหัสสาธารณะประจำตัว BLS12-381

แนวทางอื่น (อาจง่ายกว่า) คือการสร้างความมุ่งมั่นจากคีย์ BLS12-381 ข้อมูลระบุตัวตนของผู้ตรวจสอบทั้งหมด และทำการพิสูจน์การเป็นสมาชิกเกี่ยวกับความมุ่งมั่นนั้น

อย่างไรก็ตาม วิธีการนี้จะกำหนดให้ผู้ตรวจสอบความถูกต้องต้องแทรกคีย์ส่วนตัวของข้อมูลประจำตัวลงในระบบพิสูจน์ ZK เพื่อสร้างหลักฐานการเป็นสมาชิกที่ถูกต้อง และคำนวณคีย์ที่ได้รับเฉพาะ

เราตัดสินใจที่จะไม่ใช้วิธีการนี้ เนื่องจากไม่ใช่แนวปฏิบัติที่ดีที่จะแทรกคีย์ข้อมูลระบุตัวตนที่ละเอียดอ่อนลงในโปรโตคอลการเข้ารหัสลับที่ซับซ้อน และยังจะทำให้ผู้ตรวจสอบความถูกต้องเก็บคีย์ข้อมูลระบุตัวตนหลักไว้แบบออฟไลน์ได้ยากขึ้นอีกด้วย

ทิศทางการวิจัยในอนาคต

• เราสามารถหลีกเลี่ยงวงจร SNARK ทั้งหมดและดำเนินการพิสูจน์ความเป็นสมาชิกและการสืบทอดคีย์ด้วยวิธีพีชคณิตล้วนๆ ได้หรือไม่
• ที่เกี่ยวข้อง: เราสามารถมีหลักฐานพิสูจน์โปรโตคอลการเป็นสมาชิกที่มีประสิทธิภาพโดยไม่ต้องมีการตั้งค่าที่เชื่อถือได้และไม่ต้องพึ่งพาฟังก์ชันแฮชที่เป็นมิตรกับ SNARK ได้หรือไม่

รับทราบ

ขอขอบคุณ Enrico Bottazzi, Cedoor, Vivian Plasencia และ Wanseob สำหรับความช่วยเหลือในการนำทางเว็บของฐานรหัสพิสูจน์การเป็นสมาชิก

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [ethresear] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [George Kadianakis , Mary Maller, Andrija Novakovic, Suphanat Chunhapanya] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: Th
   มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว