ในเครือข่ายบล็อกเชน โหนดจะแน่ใจได้อย่างไรว่าข้อมูลทั้งหมดสำหรับบล็อกที่เสนอใหม่พร้อมใช้งาน ทำไมสิ่งนี้ถึงสำคัญ?

ในบทความนี้ เราจะเจาะลึกถึงปัญหาความพร้อมใช้งานของข้อมูล และผลกระทบที่ส่งผลต่อความสามารถในการปรับขนาดของ Ethereum

ปัญหาความพร้อมของข้อมูลคืออะไร?

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

ตัวอย่างเช่น สมมติว่า Alice เป็นตัวดำเนินการ ZK-Rollup เธอส่ง ZK-Proof บน Ethereum และได้รับการยืนยันแล้ว หากเธอไม่ส่งข้อมูลธุรกรรมทั้งหมดบน Ethereum ผู้ใช้ของ Rollup อาจยังไม่รู้เกี่ยวกับยอดคงเหลือในบัญชีปัจจุบัน แม้ว่าหลักฐานของเธอจะยืนยันว่าการเปลี่ยนแปลงสถานะทั้งหมดที่เกิดขึ้นใน Rollup นั้นถูกต้อง เนื่องจากลักษณะความรู้เป็นศูนย์ หลักฐานที่ส่งมาจึงไม่สามารถเปิดเผยข้อมูลเกี่ยวกับสถานะปัจจุบันได้

มีตัวอย่างที่คล้ายกันในสถานการณ์ Optimistic Rollup ที่ Alice ส่งการยืนยันบน Ethereum แต่เนื่องจากข้อมูลธุรกรรมไม่พร้อมใช้งาน ผู้เข้าร่วม OPR จึงไม่สามารถคำนวณใหม่หรือท้าทายการยืนยันได้

เพื่อรับมือกับสถานการณ์ข้างต้น การออกแบบของทั้ง OPR และ ZKR กำหนดให้ผู้ดำเนินการส่งรายละเอียดธุรกรรมทั้งหมดไปยัง Ethereum เป็น calldata แม้ว่าสิ่งนี้จะช่วยให้พวกเขาหลีกเลี่ยงปัญหา DA ในระยะสั้นได้ เนื่องจากจำนวนธุรกรรมภายในชุดรวมอัปเดตเพิ่มขึ้น ปริมาณข้อมูลที่จำเป็นต้องดำเนินการก็จะเพิ่มขึ้นเช่นกัน โดยจำกัดจำนวนการปรับขนาดที่ชุดรวมอัปเดตเหล่านี้สามารถให้ได้

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

ปัญหาความพร้อมใช้งานของข้อมูลส่งผลต่อบล็อกเชนในปัจจุบันอย่างไร

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

บล็อกสามารถแบ่งออกเป็นสองส่วนหลัก:

• ส่วนหัวของบล็อก: ส่วนหัวของบล็อกขนาดเล็กประกอบด้วยข้อมูลสรุปและข้อมูลเมตาที่เกี่ยวข้องกับธุรกรรมที่รวมอยู่ในบล็อก

• Block body: ประกอบด้วยข้อมูลธุรกรรมทั้งหมดและถือเป็นส่วนหลักของบล็อก

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

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

อย่างไรก็ตาม มีปัญหากับระบบนี้: จะเกิดอะไรขึ้นหากผู้ผลิตบล็อกไม่เปิดเผยข้อมูลทั้งหมดเบื้องหลังบล็อก? ในกรณีนี้ โหนดเต็มจะปฏิเสธบล็อกอย่างเห็นได้ชัด เพราะในมุมมองของพวกเขา ถ้าบล็อกไม่ได้มาพร้อมกับตัวบล็อก แสดงว่าไม่ใช่บล็อกด้วยซ้ำ อย่างไรก็ตาม light client สามารถแสดง chain header ของบล็อกได้ และไม่สามารถสังเกตเห็นข้อมูลที่ขาดหายไปได้ ในเวลาเดียวกัน โหนดแบบเต็มไม่สามารถสร้างหลักฐานการฉ้อโกงได้ เนื่องจากโหนดเหล่านั้นขาดข้อมูลที่จำเป็นในการสร้างหลักฐานการฉ้อโกง

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

มาทำความเข้าใจปัญหานี้ให้ลึกซึ้งยิ่งขึ้นด้วยตัวอย่าง สมมติว่า Alice ผู้ผลิตบล็อกสร้างบล็อก B ที่มีธุรกรรม tx 1, tx 2, ..., txn สมมติว่า tx 1 เป็นธุรกรรมที่เป็นอันตราย หากมีการออกอากาศ tx 1 โหนดเต็มสามารถตรวจสอบได้ว่าเป็นอันตรายและส่งข้อมูลนี้เป็นหลักฐานการฉ้อโกงไปยังไคลเอ็นต์ light ซึ่งจะรู้ทันทีว่าบล็อกนั้นยอมรับไม่ได้ อย่างไรก็ตาม หาก Alice ต้องการซ่อน tx 1 เธอจะแสดงเฉพาะส่วนหัวและข้อมูลธุรกรรมทั้งหมดยกเว้น tx 1 โหนดเต็มไม่สามารถตรวจสอบความถูกต้องของ tx 1 ได้

บางคนอาจคิดว่าวิธีแก้ปัญหาง่ายๆ คือให้ไคลเอ็นต์ light ทั้งหมดสุ่มตัวอย่างธุรกรรม และหากพวกเขาพบว่าตัวอย่างของพวกเขาพร้อมใช้งาน พวกเขาสามารถมั่นใจได้ว่าบล็อกนั้นพร้อมใช้งาน แต่ถ้าโหนดแสงสุ่มสืบค้นธุรกรรมใดๆ ความน่าจะเป็นที่ไคลเอ็นต์แบบเบาจะสืบค้น tx 1 คือ 1/n ดังนั้น Alice จึงสามารถหลอกล่อไคลเอ็นต์ light ให้ยอมรับธุรกรรมที่เป็นอันตรายได้เกือบทุกครั้ง กล่าวอีกนัยหนึ่ง ลูกค้ารายย่อยส่วนใหญ่จะถูกปลอมแปลง เนื่องจากลักษณะที่ไม่สามารถระบุแหล่งที่มาได้ โหนดแบบเต็มจึงไม่สามารถพิสูจน์ได้ว่า tx 1 ไม่พร้อมใช้งานในทางใดทางหนึ่ง น่าเสียดายที่การเพิ่มขนาดตัวอย่างไม่ได้ทำให้สิ่งต่างๆ ดีขึ้นเช่นกัน

แล้วเราจะแก้ไขปัญหานี้อย่างไร?

วิธีแก้ปัญหานี้อยู่ที่การแนะนำความซ้ำซ้อนในบล็อก มีวรรณกรรมมากมายเกี่ยวกับทฤษฎีการเขียนโค้ด และโดยเฉพาะการลบการเขียนโค้ด ที่สามารถช่วยเราแก้ไขปัญหานี้ได้

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

หากเราบังคับให้ผู้ผลิตบล็อกลบธุรกรรมโค้ด tx 1, tx 2, ..., txn ดังนั้นในการซ่อนธุรกรรมเดียว จะต้องซ่อนบล็อกข้อมูล n+ 1 เนื่องจากบล็อกข้อมูล n ใดๆ ก็เพียงพอที่จะสร้างธุรกรรมทั้งหมดได้ ชุด. ในกรณีนี้ การสืบค้นจำนวนเล็กน้อยสามารถให้ไคลเอ็นต์แบบ light มีความมั่นใจในระดับสูงว่าข้อมูลพื้นฐานมีอยู่จริง

Woah,นั่นสินะ?

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

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

ปัญหาในการแก้ปัญหาตามหลักฐานการฉ้อโกงคือ ลูกค้ารายย่อยไม่สามารถมั่นใจได้อย่างสมบูรณ์ถึงการบล็อกใดๆ ที่ยังไม่ได้รับหลักฐานการฉ้อโกง ในเวลาเดียวกัน พวกเขายังคงเชื่อถือโหนดทั้งหมดของตนอย่างซื่อสัตย์ โหนดที่ซื่อสัตย์ยังต้องได้รับการจูงใจให้ตรวจสอบบล็อกอย่างต่อเนื่อง

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

ดังนั้นโซลูชั่นเหล่านี้ทำงานอย่างไร?

เมื่อเร็ว ๆ นี้ ความมุ่งมั่นพหุนามได้สร้างความสนใจใหม่ในพื้นที่บล็อคเชน ข้อผูกพันพหุนามเหล่านี้ โดยเฉพาะอย่างยิ่งข้อผูกพัน KZG/Kate ที่มีขนาดคงที่ต่อพหุนาม สามารถใช้ในการออกแบบแผน Data Availability (DA) ที่ไม่ต้องใช้หลักฐานการฉ้อโกง กล่าวโดยสรุป ความมุ่งมั่นของ KZG ช่วยให้เราสามารถยอมรับพหุนามโดยใช้องค์ประกอบกลุ่มเส้นโค้งวงรีเดี่ยว นอกจากนี้ โครงการนี้ยังช่วยให้เราพิสูจน์ได้ว่า ณ จุดหนึ่ง i พหุนาม φ มีค่า φ(i) โดยใช้พยานที่มีขนาดคงที่ แผนข้อผูกพันนี้มีผลผูกพันทางคอมพิวเตอร์และเป็นโฮโมมอร์ฟิก ซึ่งช่วยให้เราสามารถหลีกเลี่ยงการพิสูจน์การฉ้อโกงได้อย่างเรียบร้อย

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

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

การแสดงแผนผังของบล็อก

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

ทางเลือกอื่นคืออะไร? จะเกิดอะไรขึ้นต่อไป?

การเข้ารหัสการลบมิติสูงและความมุ่งมั่นของ KZG ไม่ใช่วิธีแก้ปัญหาความพร้อมใช้งานของข้อมูลเท่านั้น เราได้ละเว้นวิธีการอื่นๆ บางส่วนไว้ที่นี่ เช่น Coded Merkle Tree, Coded Interleaved Tree, FRI และวิธีการแบบ STARK แต่แต่ละวิธีก็มีข้อดีและข้อเสียต่างกันไป

ที่ Avail เราได้พัฒนาโซลูชันความพร้อมใช้งานของข้อมูลโดยใช้ KZG Commitment ในบทความต่อๆ ไป เราจะกล่าวถึงรายละเอียดการใช้งาน วิธีใช้งาน และวิธีที่เราวางแผนในการเปลี่ยนแปลงพื้นที่ปัญหาความพร้อมใช้งานของข้อมูล หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ Avail ติดตามเราบน Twitter และเข้าร่วมเซิร์ฟเวอร์ Discord ของเรา

Twitter：https://twitter.com/AvailProject

Discord：https://discord.com/invite/jTkvDrZ54r

คุณสามารถติดตามบัญชี Twitter ของ Modular 101 ได้ที่: @Modular 101